On Wed, May 28, 2008 at 1:47 PM, Marc Strapetz
<marc.strapetz_at_syntevo.com> wrote:
>> It's possible that your understanding of this bug is deeper than mine.
>> Would you be willing to try writing that text... ?
>
> I will gladly formulate the problem, but regarding the resolution I'm also
> not sure -- maybe someone with more insight into merge-tracking can comment
> on the description below, assuming following repository:
>
> - trunk created from initial import at r1
> - trunk/file modified at r2
> - branches created at r3
> - branches/branch created at r4 (from trunk at r2)
> - branches/branch/file modified at r5
> - branches/branch/file modified at r6
>
> A merge from branch to trunk currently results in an svn:mergeinfo of:
>
> /branches/branch:4-6
> /trunk:2-3
>
> "/trunk:2-3" is a self-referential mergeinfo which should (and for 1.5.1
> actually will) be omitted. So the correct svn:mergeinfo would just be:
>
> /branches/branch:4-6
Hi Marc,
FWIW, in your example you could use a reintegrate merge and only
'/branches/branch:4-6' is set for mergeinfo on trunk. So that is a
good workaround for this particular example:
1.5.0.RC8>svn pl -vR
1.5.0.RC8>svn merge %MURL%/branches/branch trunk --reintegrate
--- Merging differences between repository URLs into 'trunk':
U trunk\file
1.5.0.RC8>svn pl -vR
Properties on 'trunk':
svn:mergeinfo : /branches/branch:4-6
> This can either be achieved by "reverse merging" the trunk changes with
> --record-only
That would work fine:
1.5.0.RC8>svn pl -vR
Properties on 'trunk':
svn:mergeinfo : /branches/branch:4-6
/trunk:2-3
1.5.0.RC8>svn merge %MURL%/trunk trunk -r3:1 --record-only
1.5.0.RC8>svn pl -vR
Properties on 'trunk':
svn:mergeinfo : /branches/branch:4-6
> or -- more brute force -- by manually editing the
> svn:mergeinfo property.
In general I'd advise against manually editing the svn:mergeinfo prop
unless you absolutely can't 'fix' the mergeinfo using svn merge. (And
if you find examples where you can't do what you want with svn merge
please let us know!).
> So for this very basic case, is this actually the manual fix for issue
> #3157?
Yes, removing explicit mergeinfo that describes natural history from
the *ROOT OF A BRANCH * doesn't have any ill effect that I can see.
In fact, other than with log -g, it shouldn't have *any* effect.
I am concerned about a few things though:
1) That in more complex examples determining the implicit mergeinfo
(i.e. the natural history) to remove may prove less obvious.
2) Once we have subtrees with explicit mergeinfo, if we manually
filter natural history and invalid path/revs from these, then:
2A) Elision won't work any more (at least as it's implemented today).
This is what I was getting at in
http://subversion.tigris.org/issues/show_bug.cgi?id=3157#desc8. That
may not be a big problem for users with subtree mergeinfo, they
probably have that subtree mergeinfo for a reason (e.g. they do
nothing but file merges).
2B) There may be other ill effects with subtree merges. The way the
merge editor is driven is fairly complicated when it comes to dealing
with subtrees with explicit mergeinfo, look no further than issue
#3067. I don't see a specific problem right now, but I'm not
comfortable recommending subtree mergeinfo tweaks as a matter of
policy quite yet.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-29 18:30:59 CEST