> I am currently using Subversion 1.4 and using svnmerge.py for branch
merging and tracking.
> We are exploring to upgrade to Subversion 1.5, where merge tracking
has been added.
> For those of you that used 1.4 -and extensive use of svnmerge.py - and
migrated to 1.5, how mature is the
> merge tracking in 1.5 ?
> Did you have an easy transition?
This thread details the main pitfalls that I encountered:
http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&fr
om=674983. The main take-away is that if you have a large repository (a
WC of our trunk/ is 13 GB & 10k + files), performance can be a big
problem. (I'm not sure if it's overall size or # of files that matters;
I suspect mostly the latter.)
Since that thread kind of petered out, I'll give an update here:
Further experimentation convinced me that I really don't understand how
the svn client modifies the svn:mergeinfo property, and therefore I
didn't want to try to modify it by hand. So I went with my option (2),
running separate merges into trunk/foo/, trunk/bar/, etc. instead of one
big merge into trunk/. Performance of this seems to be acceptable so
far.
Our main complaint with svnmerge.py was that the changelogs it
generated on the merge target were useless in practice, because our
weekly merges normally include dozens of revisions touching hundreds of
files. We've only done two weekly merges w/ 1.5 so far, but it looks
like it's generating much more useful change logs in the merge target.
I think that's going to end up making it worthwhile for us to deal with
the performance headaches (after all, I'm the only one who's impacted by
the performance issues, but our whole team can benefit from the more
meaningful change logs).
I'm happy to be corrected by those more knowledgeable than me,
but my impression is that svnmerge.py is a lot simpler because it
requires all the merge info to be stored in a single property at the
root of the merge target. This means it can't handle some more complex
use cases, but it also makes it a lot faster. I believe there is some
consideration of moving SVN's internal merge tracking to something
closer to this model (or at least, changes to the WC format that would
have similar performance effects), but again I don't know any details.
It should also be noted that, since svnmerge.py just runs the
'svn merge' command line under the covers, if you use it with a 1.5 svn
client, it will suffer the same performance problems.
Matt McHenry
412-690-2442 x150
Software Developer
Carnegie Learning, Inc.
Learning By Doing (r)
Helping over 500,000 students in 2,600 schools to succeed in math.
http://www.carnegielearning.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-15 21:50:27 CEST