[darcs-users] making add/remove file commute with content change

Ben Franksen ben.franksen at online.de
Mon Nov 26 22:44:40 UTC 2007

Hi Everyone

[I am not a regular reader of this list, so please bear with me if this
horse has already been beaten to death.]

In darcs, I can record changes to a file that has been renamed by someone
else and the two changes happily merge with the expected result. Formally
speaking, the two changes commute (at least, they usually do, IME). But
this is not true when adding or removing files: a change in the content of
a file (such as a hunk) always /depends/ on the file being added;
conversely a file being removed /depends/ on it being empty, i.e. all
content must have been removed. While these dependencies look quite natural
at first, this is IMO only because we are used to view source trees as
collections of file system objects. Indeed, file systems usually have such
a semantics: the file must be created before writing to it and deleting
(the last reference to) a file means that its content becomes garbage and
are thus deleted, too. However, there is in principle no reason why darcs
could not adopt a slightly different view, namely by separating the notions
of 'darcs knows about this file' and 'this file is (currently) present in
the source tree'. Thus my proposal:

*darcs should allow to record changes to the content of a file that has been
removed (or wasn't even added in the first place)*

The main advantage would be that changes which remove files would commute
with changes to their content (e.g. hunks). For instance, here is one
situation I encountered today (and which prompted the present
considerations): a co-worker deleted a directory (with all its content) but
it turned out we still need one of the files under it. Our idea was
to 'darcs mv' this file into another directory and only then pull the
(already published) patch that removes the old directory, the intention
being to keep the history of changes to the file. However, due to
the 'automatic remove contents' semantics of 'darcs remove', we the result
of the merge was a new empty file in the new directory (after resolving
conflicts). Of course we could have re-added the file's former content but
this would have defeated the purpose which was to have an uninterrupted
history of the file's content. [Eventually we worked around this by doing
a 'darcs rollback' on the directory remove.]

With the proposed full separation of add/remove from content changes, the
result of the merge would have been the old file moved to the new directory
with no changes to its content and the old directory removed. I even think
that the two changes would actually commute.

What do you think?


More information about the darcs-users mailing list