On Sun, Apr 20, 2008 at 07:43:32PM -0600, zooko wrote: > It is interesting to speculate what sort of semantics a future > version of darcs could apply to the command "darcs cp configfile > service1/configfile ; darcs cp configfile service2/configfile". At > the least, it could retain a record for documentary purposes so that > if you are later browsing backwards in history you can see service2/ > configfile marked as derived from the old ./configfile instead of (as > currently) appearing ex nihilo.
The first "problem" I come to think of is this: If only you have the cp patch, and you pull a patch of mine that adds a line 'foo' to configfile, to apply that patch it has to be commuted with the inverse cp patch, and the resulting patch mush add the 'foo' line to both service1/configfile and service2/configfile. To obliterate the patch, it must be commuted with the cp patch. Let's say darcs checks that the two 'foo' lines are identical, and removes the "copied" one on commutation. So far so good. If you try to obliterate the cp patch and have a change to service1/configfile, the commutation will fail because there is no identical change in both files of the cp. But what if you recorded identical changes to service1/configfile and service2/configfile? Darcs could detect that an "un-copy" is possible. Bug of feature?? It would also be nice to have both the cp and the move patches extend to lines, so that I can move a function from one place to another, or to another file, or copy the copyright notice from a template file to new source files. (I know nothing about what could happen on conflicts though, the dificult part of patch theory). -- Tommy Pettersson <[EMAIL PROTECTED]> _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
