Thomas F. O'Connell wrote: > > 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.
Yes, with svnmerge.py you can expect branches to contain svnmerge-* properties for other branches when you use feature branches, which IIRC you are doing. Why? When you copy the trunk to create a new branch, you are copying the svnmerge-* properties also. Some might see this as a feature since you now have the merge information from the trunk carried over -- just in case you wanted to merge between feature branches, you could now (probably) do it (depending on which feature branches were created when). However, in the use case of feature branches it doesn't really make sense and it really just causes user confusion because feature branches should only be merging between themselves and trunk. For the feature branches use case, I would recommend keeping the merge information as "clean" and lean as possible -- I do this by always deleting the svnmerge-* properties on new branches and re-initializing them with only the sources *I* know I want -- in your case, the trunk. I don't know how the merge support in svn 1.5 will handle this use case -- I hope in a more intuitive way than svnmerge.py, because in my opinion its *way* more common than the graph-based merging enabled by copying merge properties around. > 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. Nope see above. > 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? Yes, maintain the gaps. You don't want to record a revision as "merged" if it is blocked. You want to keep it available for merging, but blocked. > 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. You shouldn't need to explicitly block the reflective revisions. Try the avail command again with a -b, and see if 2990 still shows up. If it does, its a bug. The secret to -b is: there is no secret. Just use it *all* the time, no matter what, whether you think you need to or not. It will never do any harm. The only revisions you should need to block are "real" revisions that you don't want to merge, for whatever reason -- let the -b flag take care of the reflective ones. In fact, once you do a merge with -b, the reflective revisions will get added to the integrated property, so when you are following the steps, don't hesitate to "--record-only" the reflected revisions if they are in a range that has already been merged. > 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... No problem, good luck... Cheers, Raman Gupta _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
