On Tue, 27 Feb 2007 14:19:47 -0800, Eric Wilhelm <scratchcomputing@...400...> wrote:
IME, branching in svn isn't that painful, but I guess if you're trying to constantly merge-down from trunk it could be.
Yeah. Even one or two merge-downs will get painful, so you end up saving up the entire re-integration burden for the end. I've had enough bad experiences at this point that I would never want to do a long-running branch in SVN that I would eventually have to re-integrate (it's not so a big deal for e.g. release branches, obviously). We might be better off doing the cairo development in HEAD, with conditional compilation (or better, runtime switchover) between the two renderers.
As far as git for cairoification goes, though, I set up the git infrastructure to support my own work on the bbox cleanup. While it meets my needs, I'm not entirely sure that (given issues which have already been mentioned) it's ready for that kind of primetime yet.
If you just want better merge tools for svn, look at svk. With that approach, you keep the linear central model, but with a local buffer and easier branching/merging.
Been there, done that, got the teeshirt. As far as svk goes, it has the functionality, but the implementation is crap and it's painful to use as a result. Nowadays I use git-svn instead (most of my recent SVN commits actually originated in git) -- while the SVN integration isn't as nice as svk's, everything else works so much better.
Ever since we started talking about switching from CVS to SVN, I've made something of a project of trying out all the various available Open Source SCMs. At this point, in order of preference, I'd rate them roughly:
1. git 2. Darcs 3. mercurial 4. Subversion 5. Arch/bzr 6. monotone 7. svk 8. CVS
Darcs, Arch, and bzr are the only SCMs I've not actively maintained a project in yet.
-mental