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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
