Andrew Stitcher <[EMAIL PROTECTED]> wrote: > 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.
If switching technology altogether is an option (yeah, right, but let's be crazily optimistic), consider git, too. Its merge capabilities are very good. E.g., check out the man pages for these tools: git-rebase and git-rerere. And there are tons of (some say too many) examples in git's Documentation directory. Be sure to look at the very latest (e.g. 1.4.4.4 or better), since the documentation has been improving steadily. SVK was the first dVCS (distributed version control system) I ever used. I tried it almost two years ago, and really liked the ability to work totally disconnected, cheap private branches, etc. -- this was before git/mercurial were serious contenders. svk was young too, but it did work and had a stable back-end... and there was even usable Emacs vc-mode support :) Since then, I've spent a lot of time evaluating both git and hg, because I wanted to switch upstream coreutils development from CVS to a dVCS . Once you get a taste of working with a dVCS, using the likes of CVS and SVN will feel like a taking a big step backwards. I settled on git[*] and have never looked back. I flipped the switch on the upstream coreutils repository in October. Now, all changes are committed into the git repository, and automatically mirrored to the legacy (otherwise-read-only) CVS repository, so the older infrastructure still works (e.g., cvsweb). In case anyone is interested for qpid, the repo-conversion tools work pretty well. Between git's git-svnimport and tailor (http://darcs.net/DarcsWiki/Tailor, a tool to convert nearly any VCS to any other), it should be easy to perform the initial svn->git conversion. But I'm getting way ahead of myself. With inertia and all that, I suspect no one will be pushing to convert the repo to git in the short term. Probably not at all. Jim [*] I've made the git-over-hg case on a couple other forums, if you're interested let me know and I'll dig up the links.
