Alan Conway <[EMAIL PROTECTED]> wrote: > I propose we use http://www.orcaware.com/svn/wiki/Svnmerge.py to track > merges for us. It will make merging much less error prone. I'm going to > try it out on the 0-9 branch to backmerge and merge python and spec > prior to merging them to trunk. Its endorsed by the svn team and > included in the svn distribution. It can be used in conjunction with > manual merges but life will be simpler if we always use it for all merges.
If you're expecting to be involved in significant and/or continuing merge efforts, consider switching to git. Using git for merges is really a breath of fresh air when compared to CVS, SVN, or even mercurial. The Git developer community is at least an order of magnitude larger than that of mercurial, its nearest competitor in the field of distributed version control tools. To get an idea, just look at the activity (in terms of code contributions) on the two projects. The size bit matters: if something goes wrong, it is reported and fixed nearly immediately. Also, new features, interfaces, improvements, etc. are being proposed all the time. For example, there's a brand new GUI tool, "git-gui", that can ease the transition from other version control tools. When I asked about it a couple months ago, I heard that Apache didn't provide git repository hosting. That may have changed. Bear in mind that Git is no short-term panacea. The learning curve is well known to be steep. But if you can afford to take the long-term perspective, it's easy to see the benefit. You probably needn't worry about importing all SVN history into a new GIT repository. I hear that the conversion process works very well, these days. As for Git's maturity/stability, suffice it to say that if Linux development can afford to use it, then so can just about anyone else. I switched upstream GNU Coreutils development from CVS to git a few months ago and haven't looked back. If you're hesitating between git and mercurial, this is relevant http://meyering.net/dVCS.
