Looking at the subversion website it appears that svnmerge.py is now maintained as part of the subversion distribution so that makes it almost "blessed" by subversion. It looks like they are planning to use svnmerge as a sort of model for the merge tracking support in future versions of svn so it looks like it might be the best future proof solution.
Another possibility is to use SVK (http://svk.bestpractical.com/)which also supports merge tracking, and uses svn as its underlying storage and can also be used to mirror svn repositories. However this would probably only work to manage individual branches and these would then be in a different repository from the main qpid repo. I have tried to use svk to allow me to manage my own qpid development (as I don't have commiter rights yet) but I ran into some problems trying to mirror the whole qpid tree - this seems to appear when trying to mirror version 488160 of the repo. It seems to work fine though with a small branch (qpid.0-9) created after this repo version. Andrew On Wed, 2007-01-10 at 18:08 -0500, Alan Conway wrote: > Subversion, is of no help at all in tracking what has been merged from > one branch to another so the risk of double-merging is very high. > > http://www.dellroad.org/svnmerge/index claims to be a tool to record > merges in svn properties automatically avoid double merges etc. It's > been adopted by tigris and is part of the svn distribution (although not > installed by the fedora RPM package I have.) > > Anyone have any experience with this? If its any good it would be worth > adopting for qpid. Anyone know of better solutions to managing merges on > svn? > > Cheers, > Alan. >
