[Svnmerge] Lost in Properties

Tue Mar 27 06:28:19 PDT 2007

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