> and a whole bunch of really nasty ones that had bedeviled other VC > systems for ages just ceased to exist, like rename tracking (what? > you need to track renames? why not just search for similar content > when you pack? that way you can merge stuff that's similar whether > or not it originated in a rename.) The primary reason for wanting to track renames in a version control system is not storage efficiency: it is to correctly merge a branch even if files have been moved around. Git's answer to the merge problem is to infer the renames based on the file content, which works quite well except for a few cases where it doesn't (some cases with renamed directories and added files come to mind). In contrast, VCS's that do track renames generally only use the information they captured when performing the merge. This can break down in cases where a file has been split in two, since they'll often try to apply the changes to just one of the halves. One thing to note is that the data model of a VCS that tracks renames does not preclude performing git-style content based merging, while the reverse is not true. Perhaps the ideal merge algorithm will turn out to be a combination of tracking renames and content based heuristics. As both approaches have their faults, I'd prefer to keep my data in a form that tracks the renames. 5 to 10 years down the track, if it turns out that content based merges are state of the art I can always throw that information away.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds