Brief article on benchmarks of Python repository with leading DVCSen

[Stephen J. Turnbull]

Talden writes:
 > >> I would expect that most java shops will lean heavily towards explicit
 > >> renames and folder tracking specifically because of the tight
 > >> relationship between folder structure, file naming and code content.
 > >
 > > That is an argument _in favor_ of dealing with file names the same way
 > > you deal with code content. Any decent VCS detect content changes with
 > > a diff algorithm, and you still didn't give an argument to do it
 > > another way for file names.
 > 
 > No, I meant what I said.  We NEED tracked renames.

Yup.  If you do this script (the echos should be exact, content
matters) in a fresh directory,

git init
echo content >> foo
git add foo
git commit -m "create" foo
git mv foo bar
git commit -m "move" foo bar
echo more content >> bar
git commit -m "add" bar

then "git diff -M HEAD~2 HEAD" does *not* detect the rename, while
"git diff -M HEAD~1 HEAD" does.  This particular case can of course be
done at zero cost (you can just check that the list of file SHA1s is
identical across commit #2), but more generally you'd have to do a
diff on every commit, and evidently git doesn't do that.  So the more
commits, the less likely git is to detect a rename.  I can also
imagine refactorings where the majority of content moves to a new
file, and a human being must disambiguate whether the semantics are
"rename a b; add a; edit" or simply "edit".

I don't see why tracking renames would be terribly hard to add to git
(the implementation would be just a variant on reflog, for file names
rather than branch names) and I can't see a performance implication.
It's indisputable that git *does not* do it, however.

I still don't understand why this need for rename tracking doesn't
lead to a demand for defun-level tracking, too.