On Fri, Oct 14, 2005 at 12:10:07AM +1300, Martin Langhoff wrote: > The problem with "expecting the scm to deal with renames" is that > most SCMs have a very naive implementation, trying to catch renames > and similar operations at _commit_ time. That's putting the smarts > in the wrong place.
Right. Putting it in the right place is having an explicit rename command -- or better, tree-independent file ID tags of some sort or another. Like arch. > + one of those merges deals with renames: if a target file in the > patch isn't there, it walks up the commit history trying to find > the commit where we last saw a file with that name, and then > analyses that particular commit to detect the rename Boo, hiss. "Fatal flaw" all over again. Now I can never use that same file name, not unless I want to invite applying merges to the same file. Also, I have to have, at some point, used that file by its proper name in a commit. Several times now, people including myself have used arch to subsume another arch project by copying files in with the same ID. They can be named whatever they want, because the IDs remain the same. And you can replay any change for the old tree and have the changes apply flawlessly, without history lookups or a shared ancestor. Renaming is about so much more than the (petty, IMO) "purist" add+delete gripe, or the (somewhat less petty) concerns about breaking "annotate" output. Working around it will never be as efficient or flexible as a unique-ID system.
signature.asc
Description: Digital signature
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
