[darcs-users] Re: File name too long

[David Roundy]

On Fri, Oct 17, 2003 at 09:53:27AM +1000, BARBOUR Timothy wrote:
> > From: David Roundy [mailto:droundy at abridgegame.org]
> [...]
> > That's one issue.  The other (and to me almost equally important one)
> > is that as long as the filenames look human-readable, humans will try
> > to read them.
> 
> Perhaps it is a bad thing for casual users to read the repository, but
> probably not so bad for administrators. Maybe it is okay provided people
> understand that they must know what they are doing.
> 
> Do the human-readable names have any benefit when you are debugging darcs
> or recovering from a bug ?

They are convenient, since it's easy to remember the first few characters
of the patch name and tab completion does the rest, but the date would work
just as well, except that it's not so easy to remember.

> > If the _darcs/patches directory looks like a bunch of hashes (which is
> > what it really is, in either case),
> 
> How do you mean ?

In either case, you can go from a patch ID to a file name, but not in the
reverse direction.

> > people will look elsewhere, which is
> 
> Where should they look if they are worried about the integrity of a
> repository ? Keep in mind that some repositories contain millions of
> lines of code (the CVS repository here holds at least 3 million lines).

They should run darcs check.  If darcs check succeeds, their repository is
consistent.  There really is no other way to determine the consistency of a
repository.  Certainly not by looking at the patches.

Now if you mean where should they look when they *know* they have a corrupt
repository, that's another question.  From the output of a failed darcs
check to a file, they can see which patch failed.  Then things get a bit
more complicated, trying to see why it failed.  Fortunately I don't know of
anything other than hardware failure (or getting killed during a write
operation) that will make darcs corrupt a repository.  So with the natural
backup that comes from every developer having at least one complete copy of
the repository, I think in most cases identifying corruption is
sufficient.

> > good, because darcs itself looks elsewhere, so people will more likely
> > be looking at the data that is actually meaningful.
> 
> When I was considering whether to adopt darcs, the clarity of the repository
> format appealed to me, not because I wanted to use it as a source of
> information, but so I could (probably) fix it if it was broken. For a new
> user, who naturally has some qualms, the human readable format is
> reassuring. One of the virtues of CVS is its fairly readable repository,
> which allows administrators to fiddle with it occasionally (probably only
> needed because of deficiencies in CVS, even though CVS is mature). One
> criticism of VSS is its binary repository format - no one can tell what is
> going on in there.
> 
> Maybe it would help to retain the option of writing the long-filename
> hard links, and mention it in the manual. Another handy thing might be a
> pair of tools for readily converting between the name and the hash.

Well, leaving at the date in hash is sufficient to allow you to access any
patch you like.  And you can always simply grep (or zgrep, if you use
compression) for the patch names.  It's not that hard, since the repository
*is* in a human-readable text format, even with the new hashes.
-- 
David Roundy
http://www.abridgegame.org/darcs