subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Date Thu, 02 Apr 2015 18:00:08 GMT
Pete Harlan wrote:
> Julian Foad wrote:
>> 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.
> Thank you very much for your email, and its articulation of the
> history and current state of the issue!

You're welcome.

> I am absolutely willing to help as much as I can.  My interests are
> guided by the only way I've used or plan to use Subversion: root-level
> branching and merging in single-revision checkouts.  I'm aware that
> Subversion is designed to handle vastly more complex uses; I have some
> understanding of that but little to no experience and my time budget
> for exploring there is limited.


> In your case #3 above, where a user commits in a subtree after
> initiating a root-level merge, I would think an appropriate behavior
> would be for Subversion to throw an error [... or warning ...]

Sure. The hard part is not deciding whether to throw an error or issue
a warning or commit with the mergeinfo that applies to the subtree;
nor implementing one of those options. The hard part is designing the
idea of "this working copy is now in a merged state", what operations
this state should affect (including commit), how and when it should
get into and out of this state, and how to present this state to the
user (in feedback notifications, status, etc.).

> For case #1 (subtree conflict), you're saying that for one user
> preference, merge resolution would be responsible for saying "Okay,
> there was this subtree merge conflict here, but the user is saying
> it's resolved as part of the merge, so I don't need explicit subtree
> mergeinfo any longer; I'll delete it."  And for the other preference,
> merge resolution would say "Okay, there was this subtree merge
> conflict here, and the user has decided to omit this subtree from the
> merge altogether; I'll keep the mergeinfo and mark it appropriately.
> [how?]"  I would expect the first situation to be vastly more common
> than the latter, but I appreciate that you want to handle both cases.

Yes. I agree the first situation (resolved as merged) would be vastly
more common. I'm just trying to say that the concept of being able to
have part of the tree recorded as "not merged" already exists, and the
problem is we don't make it clear to the user whether that outcome is
going to happen or has happened. We need clarity. A policy that that
shall never happen except through very explicit user request would be
one way to help achieve clarity.

> What currently happens is that the mergeinfo doesn't record anything
> for the current merge (it stays the same as the root mergeinfo was
> prior to initiating the merge).  If a later merge modifies a file in
> the subtree then it gets updated to be almost but not quite the same
> as[1] root mergeinfo, but not until then.

Ugh. :-)

> [1] See,
> where the revisions recorded don't match the message about them.
> This leads me to believe that merge resolution is where the change is
> likely to belong to address the concern I have.  On the other hand,
> since in this situation it doesn't look like anything is prepared to
> do something useful with the mergeinfo that appeared, perhaps it's
> easier to stop it from appearing until the time when the other pieces
> are in place.  My level of ignorance regarding that statement is
> large, because I don't know Subversion internals or the ramifications
> of this outside the simple ways that I use the tool.
> If you have suggestions for how I could further help this issue along,
> please let me know.  And thanks again very much for your time.

It would help to catalogue the various cases. Maybe start with an
premise that a whole tree merge should not generate any subtree
mergeinfo and start finding the exceptions that currently occur.

Another way to help would be to think about how the client could
present the "WC is in a merged state" notion, and how that would
affect various operations. Just assume that we can implement it, and
imagine how it should behave in order to be useful. Is there a hard
dividing line between "is" and "is not" in a "merged" state for the
whole WC -- what if we *want* to merge subtrees separately? Does this
"state" need more degrees of subtlety in some other way too?

- Julian

View raw message