On Feb 17, 2008 3:34 PM, Santiago Gala <[EMAIL PROTECTED]> wrote: > Also: you keep a long term branch for doing some refactoring, and you > fix small bugs both in HEAD and in a release branch, merging and > backporting/forwardporting as you go. Again, something like git makes > the work simpler and keeps the disk requirements under control.
In an attempt to stop some of the outright FUD in this thread before it goes on to yet another mailing list... I've found that svnmerge.py (distributed with SVN) handles pretty much all of the branch/merge tracking capabilities that I personally care about. (The drawback is that it isn't as efficient as we'd like, but it's good enough. The 1.5 stuff is *way* faster.) From your statements, you probably haven't bothered to try svnmerge.py (usable with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It makes it pretty brain-dead simple to handle most branch-oriented merging cases. There are a few pathological cases that don't work well, but that's 'reflective' merging which isn't the 95% use case - so it got punted to post-1.5. (svnmerge.py is probably the 80% use case, with 1.5 merge tracking being 90%, and reflective merging being that last gap...) FWIW, for svn.apache.org, I have a feeling we'll probably be a tad aggressive on rolling out 1.5. (Besides merge tracking, there are a number of excellent features in 1.5: changelist support, interactive conflict resolution, read/write transparent proxies, integrated 'diff -x -p' support, substantial svnsync speed improvements, partial svnsync ability, etc.) Note that nothing is stopping you from using svnmerge.py today. If folks are going to complain about switching to another SCM because of a lack of decent merging, then they owe it to themselves to check out what Subversion can actually do rather than what they think it can do... -- justin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
