Comment 21 for bug 269095

@richard, posting # 20:

True. I have used them all - RCS, CVS, svn, svk, hg, git and bzr. All have their problems, but in my opinion bzr is still the best choice for version control of "normal" source code.

Git might be better when managing patches - but only because patches are usually individual entities which no or neglectible version history of their own. (Usually, new patches are applied over existing ones instead of modifying patches. DARCS is even based on that idea.)

Regarding directories, I think bzr's feature to track individual directories cannot be overemphasized. Especially when merging. Try that in git: Start with some files in one directory, fork off a branch, then change the name of the directory in one branch. From now on, you have to tell git on *every* merge that it should merge the files in the old directory name of the original branch with those in the new directory name of the new branch. Every time! Git is just too dumb to remember it.

Regarding "cp", as far as I remember svn can do it, and therefore also its "distributed brother" svk. I have used svk for some time, but it was really no fun. Lousy documentation, lots of bugs and tons of ugly Perl code. Managing it was really challenging. Git might be hard to learn, but I felt svk's repository/branch management to be even harder.

IMHO Mercurial is the "easiest" version control system to learn, and I tend to recommend it to SCM beginners.

However, it has many shortcomings when compared to Bazaar, most notably its weak branch support and the exceptional stupid way it uses to store commits for different branches in the *same* repository (does not apply for the one-branch-one-repository approach).

On the other hand, Mercurial provides "cp" and Bazaar doesn't...

Well, let's hope some day this will change.

In the meantime, I suggest the following approach to ameliorate the situation: Whenever a "bzr cp" would be adequate (but isn't available as we know), do the following:

* Make sure there is a commit reflecting the state of the file to be forked. That is, if the file has changes, commit them *before* doing the "cp".

* Copy the file, add the copy to bzr, and commit the addition before *changing* the contents of the copy.

This approach will make sure there is a commit with the file using the original name and a later commit containing a copy of the file under a new path/name, but both files can be linked by their identical contents.

When "bzr cp" will be later added to Bazaar, it might be possible to write some sort of "rebase" tool which re-writes the version history, finds the files with the same contents in different versions, and infer a "bzr cp" from this.

Actually, this is how git detects renames nowadays. And aside from evil special cases such as renaming different files with identical contents it works surprisingly well.