On Mar 7, 2007, at 7:39 PM, Raman Gupta wrote: > Thomas F. O'Connell wrote: > >> Here is the use case I'm trying to achieve. If there are better >> practices out there that use svnmerge.py, then I'm all ears. >> >> trunk >> branches/branch-1 >> branches/branch-2 >> ... >> branches/branch-n >> >> With the style of development for this project, each of the >> branches is >> typically a major feature branch, all of the changes of which >> eventually >> need to land on trunk. But trunk needs to be left in a state from >> which >> releases can easily be created. Most minor bug fixes are performed >> directly on trunk. Often, features from the branches will land on >> trunk >> and then be enhanced in the same branch. And it's nice for branch- >> x to >> pick up the changes that landed on trunk from branch-y. > > I think this is a pretty normal process and one that svnmerge.py > should be able to easily handle, if handled with care. > >> Honestly, I'd like to wind up resetting everything based on the trunk >> and possibly re-initializing all branches, but I'm not even sure >> about >> the safest way to do this. I've got some changes in the branch >> currently >> exhibiting the problem that I don't want to lose revision history >> for. > > I think this is a good idea since it seems like your svnmerge.py > information is pretty fubar'ed. What I would do is this (untested): > > 1) Figure out which revisions have already been merged between trunk > and every branch, and vice-versa. Ditto for revisions that have not > been merged (and therefore are available) but should be blocked. The > svnmerge-integrated and blocked property will reflect these values, > plus some administrative revisions, when you're done. > > 2) "svn pd svnmerge-integrated" and "svn pd svnmerge-blocked" on every > trunk and branch. > > 3) On the trunk, execute "svnmerge.py init <branch>" for every branch. > > 4) On the trunk, execute "svnmerge.py --record-only -r <revlist> merge > -S <branch>" for every branch, where revlist is the list of already > merged revisions from step 1. Include in this list the revision > created in step 2. > > 5) On the trunk, execute "svnmerge.py -r <revlist> block -S <branch>" > for every branch, where revlist is the list of revisions from step 1 > that should be blocked. > > 6) Repeat steps 3, 4, and 5 for every branch, with trunk as source. > > 7) From now on, always use -b when merging. > > Cheers, > Raman
Okay, picking up an old thread here. I had some personal computing woes of my own that took me away from resolving this issue, but I'm now working on step 1 from the instructions above. It's raised a few issues. I figured my starting point would be to look at svn pl -- verbose for trunk and all branches just to see how far off svnmerge- integrated and svnmerge-blocked were because this repository is not particularly commit heavy, and there are only a couple of active developers. Based on the overall setup I describe above, how should I expect my svnmerge- properties to look on individual branches? Should the branches have any information about each other considering that I am merging all information bidirectionally through trunk? I'm currently trying to compile information about what I need for merge --record- only and block, and I would've suspected that I would only need to use trunk as a source on all the branches. What I'm seeing, though, is that the branches currently have -integrated and -blocked information about each other. I'm wondering if this is because many of the new branches were unintentionally initialized from a trunk that had itself as a source. For instance, in branch1, I see something like the following from svn pl --verbose branch2: Properties on 'file:///home/svn/branches/branch2': svnmerge-blocked : /branches/branch3:2663,2804,2848 /trunk: 2932,2955,2984 svnmerge-integrated : /branches/branch3:1-2847,2849-2894 /branches/ branch1:1-2528 /branches/branch4:1-2833 /trunk: 1-2931,2933-2954,2956-2983,2985-2992 Based on the analysis and instructions above, I would expect to see only trunk. On a related note, I'm trying to establish what the -integrated and - blocked properties should look like as far as continuity. Should one branch have holes in these properties where there was activity between trunk and another branch? E.g., here's the current output from svn pl --verbose branch3: Properties on 'file:///home/svn/branches/branch3': svnmerge-blocked : /trunk:2805-2806,2834 svnmerge-integrated : /branches/branch1:1-2528 /trunk: 1-2803,2807-2831,2883-2884,2897-2931,2933-2954,2956-2983,2985-3009 In svnmerge-integrated for trunk, here, there are gaps corresponding to svnmerge-blocked for branch2. Is that to be expected, and do I want to maintain these gaps when specifying my revlist for the -- record-only merge in step 4 above? The final thing I'm trying to puzzle through is how to determine, between branches and trunk, exactly which revisions, including ones that have already been merged, are bidirectional. For completing step 5 in the recommendation above, should I be taking care to block historical revisions that have already been merged as blocked, or should I only be attempting to block new, unmerged revisions. I'm assuming that the only revisions that would need blocking in step 5 are revisions that are reflective, right? E.g., here's svn pl -- verbose trunk: Properties on 'file:///home/svn/trunk': svnmerge-blocked : /branches/branch5:2954,2982-2983 /branches/ branch3:2663,2804,2848 svnmerge-integrated : /branches/ branch2:1-2931,2934-2989,2994-3001,3008 /branches/ branch5:1-2953,2955-2981,2984 /branches/ branch3:1-2847,2849-2894,2899-3094 /branches/branch1:1-2528 /branches/ branch4:1-2833 /trunk:1-2527 Currently (before I've commited any of the reset process steps), svnmerge.py avail -S branches/branch2 in trunk reveals the following: 2933,2990-2993,3002-3007,3101-3103 r2990 is a revision in branch2 where revisions 2955,2984-2985 were blocked. So when I'm building my record-only and block lists for resetting, what do I do with r2990? I would think I would want to block it in trunk. Thanks so much for all the assistance so far. I've learned quite a bit! But clearly there's still quite a bit to learn... -- Thomas F. O'Connell optimizing modern web applications : for search engines, for usability, and for performance : http://o.ptimized.com/ 615-260-0005 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
