[Svnmerge] Lost in Properties

[Raman Gupta]

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