On Tue, Mar 31, 2015 at 8:05 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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
[...]
>
> [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.
Thank you very much for your email, and its articulation of the
history and current state of the issue!
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, rather than trying to do
the strange thing that it seems that the user is now asking for. Or
if an outright error isn't desired, at least, "You initiated the merge
at $path but you're now asking me to commit only $subpath; are you
sure? [y/N]". And then confirm again if they say yes because they're
probably wrong ;-)
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.
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.
[1] See http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260,
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.
--Pete
Received on 2015-04-02 19:00:58 CEST