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? Cheers Ben _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
