On Wed, Oct 14, 2009 at 11:29:03 -0300, Marco Túlio Gontijo e Silva wrote: > From my point of view the changes between records should be minimized. > If the user want to store some history information, is should record it. > If it has undone some change before recording, that change should not be > shown in the patch.
I think everybody agrees with this. The question is whether or not it's always practical to implement. I sure hope it will be! > Why is there the need to do > > hunk ./file 1 > -file > > before > > rmfile ./file > > ? > > Couldn't rmfile store in itself the content of the removed file? I > think this would solve this problem. First: we should be clear that any changes of this sort would require a new backward incompatible format. Which is not to say that we shouldn't think hard about what our patches are and how they should (eg merge); after all, that's why we're still working on Darcs 3 and that's why we're still working out things like solutions to the add-add conflicts problem, character-diff patches and hunk moves. So the kind of solution being discussed is strictly a long term affair. If there is a more immediate way to go about it, great! Just know that this is not it :-D Second: maybe it was just a question of keeping things simple. Rather than have a notion of hunk in three places (addfile, hunk, rmfile), we just have it one place. Simplicity is good; it means, for example, we don't have to worry about how to do conflict marking between rmfile hunks and regular hunks. Although note that in Marco's solution, at least commutation wouldn't be any harder to define (presumably), since hunk patches don't commute past rmfile anyway... -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
