User: Password:
Subscribe / Log in / New account

Ten-year timeline part 6: almost to the present

Ten-year timeline part 6: almost to the present

Posted Feb 28, 2008 20:18 UTC (Thu) by njs (guest, #40338)
In reply to: Ten-year timeline part 6: almost to the present by nix
Parent article: Ten-year timeline part 6: almost to the present

It's easy for the VCS to detect when the user has forgotten to record a rename -- there's an
inconsistency between the VCS's idea of what the tree should look like and what the tree
actually looks like on disk.  (This is true both when the VCS thinks a rename should have
occurred but none did, or vice-versa.)  Most VCSes already refuse to allow a commit when
there's a "missing file" situation like this.  So just add some code to that routine that says
"such and such files are missing -- hmm, but it looks like very similar files are in an
'unknown' state over there.  (Do you want me to record the following renames to fix things
up?)/(Do you want me to rename the following files on disk to fix things up?): a -> b, c ->

This combines the ease-of-use of the automatic content tracking systems with the
predictability of explicit rename tracking.  It still doesn't help with files getting cut in
half, though, sure.  (Handling that case in an explicit and predictable manner looks hopeless,
though, which is why I personally would prefer that such heuristics only be used as part of a
manual merge with a human checking the results.  YMMV.)

Hooking into the FS doesn't really help, and probably hurts, because a VCS "rename" is at a
higher semantic level than a FS "rename".  It's perfectly common for people to, say, copy a
file, edit the copy, and then replace/delete the original.  rename(2) is a way to move bits
around, "myvcs rename" is a way to record intentions.

(Log in to post comments)

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds