[darcs-users] File name too long

Zack Brown zbrown at tumblerings.org
Mon Oct 13 13:16:41 UTC 2003


On Mon, Oct 13, 2003 at 07:42:04AM -0400, David Roundy wrote:
> On Mon, Oct 13, 2003 at 10:09:41AM +1000, BARBOUR Timothy wrote:
> > Another advantage of the current scheme is that the repository is
> > human-readable. I find it reassuring to look in the patches directory and
> > see my changes there. If the patch filenames were hashes, it would be harder
> > to see what patches are present (maybe other tools can make up for this).
> 
> In a sense, that's one of the reasons why I'm considering changing the
> scheme.  Looking at the patch filenames *doesn't* tell you what patches are
> actually in the repository, since some of them may have been removed.

Why not keep removed patches in a subdirectory?

>  The
> correct low-level way to see what's in the repo is to look at the
> _darcs/inventory--and then perhaps the contents of _darcs/inventories, if
> the inventory has been broken up into multiple pieces.  Alas, if I switched
> to using hashes, the contents of _darcs/inventories will also be
> human-unreadable...
> 
> On the other hand, the reason I don't delete the patch files when the
> patches are removed is so in case of emergency (e.g. you unpulled a patch
> that you meant to unrecord) their contents can be examined--this would be
> more tedious if the filenames were hashes.

There's a lot to be said for human readability. But I think using filesystem
commands to analyze a repository is just a workaround for functionality
darcs itself should provide. The mechanism to analyze the repository history
should be allowed to grow more complex and subtle over time, something normal
filesystem commands probably won't do, or not significantly. Personally,
I'd like to be able to give commands to do something like list all patches
that were removed in the last 24 hours, that touched file printers/tandy.c,
and where the modification included the addition (as opposed to the deletion)
of text matching the regular expression "sp[tT]mr_(out|in)_sync"; and I
want them all listed in order of the magnitude of the change they made to
the file. There are tons of other subtle controls that could be useful as
well. The proper place to provide that functionality, it seems to me, is
within darcs itself. 

The real problem with the current scheme, however, may just be cultural. darcs
encourages the use of long patch names because of the user interface.
Just by calling it a "patch name" instead of a "file name" is enough to
encourage people to write very long descriptions. If instead, you ask
them to choose a short identifier for the patch file name, you'd
probably do a lot to prevent darcs choking on a long name.

Be well,
Zack

> -- 
> David Roundy
> http://www.abridgegame.org
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown




More information about the darcs-users mailing list