[darcs-users] adddir and patch dependencies

David Roundy droundy at abridgegame.org
Sun Nov 7 14:13:13 UTC 2004

On Thu, Nov 04, 2004 at 09:49:26PM +0100, Nils Decker wrote:
> yesterday i converted a large repo from svn to darcs. Then i tried to
> unpull a patch that adds a single, never again touched binary file.
> This wasnt possible, because many patches depend on the adddir /doc.
> Adding the first file in a directory also adds the adddir to the patch.
> All patches for later files in this directory depend on this patch.
> This could be avoided by seperately recording adddirs, but that would be
> tiresome.

This is really is what changesets are about.  When you group changes
together, they stick together and are indivisible.  The only reason I can
see that this poses a problem is because you are using an automatic
conversion tool to make your changes.  That conversion too could either be
made to add directories separately, or told to avoid certain patches (which
have files you don't want).  Or, you could leave the change in there
(presumably the point of doing the conversion was to keep the history) and
then remove the file from the darcs repo after the conversion is complete.

> It seems to be no state to a directory other than its presence. Is a
> seperate hunk needed for this simple information? Obviously, if there is
> a addfile into a directory, the directory has to exist.
> Without the adddir everything would work like now except that there were
> no way to record empty directories.

Hmmmm.  Interesting idea.  The scary part would be directory renames.  The
commutation of directory renames with files would be fine , but I'm afraid
you might run into trouble with directory renames, since their commutation
wouldn't be bounded by the adddir and rmdir.  Imagine

addfile foo/bar (implicitly creates foo/)
mv foo baz

which would obviously commute to

mv foo baz (but foo doesn't exist!)
addfile baz/bar (implicitly creates baz/)

One could resolve this by declaring that a mv patch is a noop if there is
no such file or directory, but I'm afraid this might lead to
complications when it comes to merging changes.

On the whole, I think we're better off without "virtual" directories.  It's
not just the existence of a directory that darcs keeps track of, but also
its "identity."  A file introduced into a given directory goes into *that*
directory, not another directory that might have the same name (due to
renames).  This is an important, and nontrivial, feature.

> I think this change could be implemented without breaking darcs and old
> patches, but i am no expert on darcs...

That's distinctly possible, but it's very scary.

> PS: when pulling a patch that rmdirs a directory with non-darcs files in
> it, the directory is silently ignored. Darcs should print a message,
> "could not delete directory foo because it is not empty". The user can
> cleanup himself.

Indeed, if you want to submit that to the BTS, it's definitely a good idea
(but not trivial to implement).
David Roundy

More information about the darcs-users mailing list