Version Control Wish
A lot of smart people have thought much harder than I have about version control systems, and I am by no means an expert on them. That said, this is what I want from a VCS, beyond the obvious: I want to be able to name a patch. I want to be able to easily transfer that patch from one branch to another. I want to be able to add chunks to the patch, and modify existing chunks. If I earlier transferred the patch to another branch, I want to be able to easily move the modifications I made.
Clearly there is a sense in which a patch is a branch. But it isn’t a branch in the usual sense. I may have several active patches which live on my development branch. When I update my development branch–sync it to the master sources, or in general to other repositories–I want my patches to update also. When I want to move a patch to a release branch, I want the VCS to roll the patch back to the current merge point of the development branch and the release branch, and to apply that modified patch to the release branch.
For example, let’s say that patch P was started on the development branch at version Rd. Let’s say that release branch B was branched off of the development branch at version Rb. I do some work on P, and then I update the development branch to version Re, and then I do some more work on P. Now I’m happy with patch P and I want to put it on the release branch. I want the VCS to get P out of the development branch. I want it to reverse apply the diffs from Re back to Rb. I want it to take the resulting diff and apply it to the release branch.
Then i want to work on patch P some more, and then move it over to the release branch again. Now I want the VCS to pick up the changes since I last moved it over and only apply those changes–after, of course, removing any changes I dragged in from other people.
I want P to have a name, not a revision number, and I want these operations to be simple VCS commands, not complicated scripts.
Naturally merge conflicts are possible at several different stages here, and the final output may have to include several different bits of source code for each conflict. Or perhaps the VCS could ask me what to do as it goes along, that would be OK.
These are the sorts of operations I find myself doing fairly regularly. Obviously I can do them with any VCS, by using manual bookkeeping and attention to detail. I have yet to find any VCS which makes them simple.
rskrishnan said,
July 24, 2008 @ 10:12 pm
Nice summary of “what I want from a VCS” !! Now if some of the vcs vendors would read, and more importantly _take this to heart_ life would be much better.
I’m yet to see a VCS that will move a patch backwards that is on Re –> Rd (i.e. “backporting” a patch). Neither git, nor perforce, and surely never ClearCase seem to be able to deal with this sort of request well (specially if the delta between Rd and Re is non-trivial). With ClearCase ranking high on the “yuck” factor.
I like git mostly for it’s speed and “everything is local” mentality - makes disconnected operation much more pleasant.
Ian Lance Taylor said,
July 25, 2008 @ 6:43 am
The two systems I’ve been hearing recommendations for are git and Mercurial.
adis said,
July 25, 2008 @ 7:20 pm
Maybe you can (ab)use Mercurial Queues for some of your wishes? With some proper commit hygiene, backporting patches should be fairly easy as well.
Darcs “Theory of patches” is also an interesting read: http://darcs.net/manual/node8.html
ncm said,
July 26, 2008 @ 1:11 am
You might get what you want from Monotone — particularly if you provide patches yourself. Civility and rigor seem more characteristic of that project than some others, under Nathaniel Smith’s leadership.
Ian Lance Taylor said,
July 28, 2008 @ 10:07 pm
adis: As far as I can tell, Mercurial Queues are quilt for Mercurial. That’s useful, but it’s not what I’m after. That requires me to do a lot of the bookkeeping myself.
ncm: I am skeptical that monotone can handle the gcc repository efficiently. I’d be happy to hear otherwise.