Hello.
Firstly I'd like to say thank you, Pete, for bringing up this issue
and discussing it so clearly.
I had a think about this the other day and chatted with the others on IRC [1].
I picked this old email from this thread to reply to, as it's got me
in the CC and is as good a one as any to reply to.
Much of this has been said already, but here's my 'take' on the problem.
On 2015-03-16, Pete Harlan wrote:
> On 2015-03-14, Pete Harlan wrote:
>> My expectation as a naive user is: I initiated a merge from the root
>> of a branch (or trunk), I told svn to merge the root of another branch
>> (or trunk), and I resolved all reported conflicts (however complex).
>> Unless I've explicitly told svn otherwise, I expect svn to consider
>> this a full merge, and not create separate mergeinfo for any interior
>> nodes.
Yes, I completely agree. The user has requested a full merge and
sorted out all the physical and semantic conflicts. The mergeinfo is
meant to record the intent of the merge, as you correctly argued,
rather than to record exactly where the physical content changes were
made in the target branch in order to achieve the desired result [2].
Therefore the merge should be recorded, in the end, as a complete
merge, with no subtree mergeinfo needed.
There are two or three things going on. (I'm going to be critical of
Subversion here.)
1. The user should always have the choice to record a subtree as
'merged' or as 'not merged'. Subversion currently doesn't make this
choice easily available, and doesn't clearly report or document what
it's doing, in all the cases that can occur during a merge such as
- a conflict occurs
- skipped because subtree is missing, obstructed, or still
conflicted from an earlier merge
- subtree is switched
and across different operations on the subtree, such as
- revert changes to subtree
- copy/move/rename the subtree
In some of these cases it records mergeinfo indicating 'merged', and
in other cases indicating 'not merged'.
2. Subtree mergeinfo was never designed to be an absolute indicator
that a subtree merge had been done. In other words, there was no
specific rule that a complete tree merge must result in no subtree
mergeinfo. After 1.5 was released and some work flows resulted in lots
of subtree mergeinfo (especially, I remember, copies added subtree
mergeinfo), there was a succession of refinements aimed at reducing
the number of nodes having subtree mergeinfo.
When Subversion creates (or fails to elide) unnecessary subtree
mergeinfo, we classify that as suboptimal performance but not an
outright bug.
In fact, the plan for eliding mergeinfo is not simply "always elide
any unnecessary explicit mergeinfo". In some cases it's more like
"elide unnecessary mergeinfo if we're touching that node anyway, but
don't touch other nodes just to elide their mergeinfo". In other
words, trying to minimize the number of changes to be committed. I
don't know the details of when we do what.
3. The Working Copy and its user interface doesn't keep track of what
merge(s) you have done, it just tracks the resulting mergeinfo
properties. As a consequence, for example, after doing a merge to the
root of the WC if you try to commit a subtree, it won't notice that
actually to commit the subtree along with the subtree's mergeinfo it
needs to put a mergeinfo property on the subtree.
What you will find is that the merge implementation has not carefully
followed a consistent set of rules or a 'mental model'. There have
been rules and mental models but they have not been formally
identified and kept consistent. I'd love to be able to point you to
the rules as documented, but unfortunately can't. And there are still
cases where it does something that's clearly wrong or inconsistent.
What to do?
In the case you identified, I certainly agree it's bad behaviour, not
what we want. But it's not easy to know exactly which cases need
fixing -- or if "fixing" this case would make it inconsistent with
other cases -- without first cataloguing the existing behaviour over
all or most cases. If somebody wants to work on fixing this case,
that's fine, what I'm saying is I'm more interested in figuring out
the bigger solution.
Pete, you seem to have a good grasp of this stuff. Would you be
willing to help? Either in a small way, anything from saying "please
just fix this case" upwards, or in a bigger way by helping to
catalogue the existing behaviour and decide what we should do about it
overall? No worries if not, but we do rely on those who have an
interest.
- Julian
>> So I think it would be worth updating "svn resolve" to, by default,
>> take action to trust the user and mark this as a full resolution. If
>> the user needs to take an extra step or add a new parameter to get
>> that effect, would that not feel like a regression compared with 1.7?
>
> A colleague argued that creating the mergeinfo for a subtree in this
> case (root->root merge) is a simple bug because mergeinfo says what
> inputs were considered to come up with the result, not just those that
> were used.
>
> 1. If the resulting mergeinfo is the same as for root then it's
> unnecessary, so the bug is that it is explicitly listed at all.
>
> 2. If the resulting mergeinfo is different than then root one then
> it's incorrect, because it's claiming that the subtree working copy
> represents the merge of a different set of branches and revisions than
> the root working copy it's included within.
>
> In other words, it would always be wrong for a merge to introduce
> explicit mergeinfo for a subtree of the merge point.
>
> This implies that the fix wouldn't be to change how resolve works, it
> would be for "svn merge" to not create the property on the subtree in
> the first place.
>
> What do you think?
>
> Thanks,
> Pete
[1] IRC log: http://colabti.org/irclogger/irclogger_log/svn-dev?date=2015-03-30#l74
[2] I nearly said 'correct result' but, as you know, as far as
Subversion is concerned a merge result is inherently subject to the
user's judgement and cannot be called Right or Wrong.
Received on 2015-03-31 17:13:00 CEST