[Svnmerge] Multi-directional merges with multiple branches

Steven Shanks sshanks at valleyt.co.uk
Thu Oct 26 06:22:22 PDT 2006


Hi,

I have recently added another branch to one of my Subversion 
repositories, so it now looks like this:

repos/trunk
repos/branchA
repos/branchB

Both of the branches and the trunk are considered "current", and so I am 
attempting to keep track of bug fixes etc between all three versions.  I 
have set up svnmerge.py as follows:

[trunk] svnmerge.py init [branchA]
[trunk] svn commit
Revision 100 committed.
[trunk] svnmerge.py init [branchB]
[trunk] svn commit
Revision 101 committed.

[branchA] svnmerge.py init [trunk]
[branchA] svn commit
Revision 102 committed.

[branchB] svnmerge.py init [trunk]
[branchB] svn commit
Revision 103 committed.

However, I'm not sure this is the right way to go about this, 
particularly when it comes to blocking revisions.  Say I make some 
changes in branchB and commit them:

[branchB] svn commit
Revision 104 committed.

Obviously, this revision should now be available in trunk:

[trunk] svnmerge.py avail -b -S [branchB]
104

But for whatever reason, I decide that this fix only belongs in branchB:

[trunk] svnmerge.py block -r104 -S [branchB]
[trunk] svn commit
Revision 105 committed.

This solves the problem for trunk, but now I will have another revision 
available for branchA:

[branchA] svnmerge.py avail -b
105

If I block this revision (105) in branchA, then svnmerge.py will 
recognise that this was a bi-directional block, and the problem will 
disappear, but I have now had to block several revisions after 
committing one.  If it became necessary to add a third or fourth branch 
to this setup, then the problem only increases.

Does anyone have any suggestions on how I might avoid this problem, or 
ways I could change my setup to minimise it?

Thanks for any help, and apologies for the length of this post!

Cheers,
Steve



More information about the Svnmerge mailing list