Pete Harlan wrote on Mon, Mar 30, 2015 at 08:40:46 -0700:
> On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700:
> >> On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> >> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
> >> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
> >> >>> Is it accurate then to say that Subversion may generate explicit
> >> >>> mergeinfo whenever it decides that there is something useful to record
> >> >>> about the set of revisions that contributed to a given node, and that
> >> >>> svn:mergeinfo properties may appear in subnodes as part of normal
> >> >>> Subversion merging bookkeeping, and this doesn't imply lack of a full
> >> >>> root->root merge or other user shenanigans?
> >> >>>
> >> >>> I appreciate your time on this.
> >> >>
> >> >> Hi,
> >> >>
> >> >> Is that an accurate description? I'm not trying to file a bug report
> >> >> anymore, I'm just looking to understand the intent of this property so
> >> >> we can know what to expect when moving forward from 1.7.
> >> >>
> >> >> Thanks for your help,
> >> >>
> >> >
> >> > Yes, I think it's possible that svn records mergeinfo on subnodes
> >> > (directories or files), even if there is nothing to do there. It
> >> > happens for instance when that subnode already has some explicit
> >> > mergeinfo (explicit, as opposed to inherited), because of some
> >> > previous merge. As soon as a node has explicit mergeinfo, that
> >> > explicit mergeinfo needs to be updated on every merge to the root of
> >> > the branch.
> >> >
> >> > I'm trying to explain from memory here, possibly not entirely
> >> > accurate. I think you should really start by reading this article [1]
> >> > describing the merge tracking introduced in 1.5 (it has undergone
> >> > changes and many bugfixes since then, but the underlying principles
> >> > are still the same). It explains nicely some important terms such as
> >> > 'inheritable mergeinfo', 'explicit mergeinfo', 'mergeinfo elision'
> >> > etc..
> >> >
> >> > Also, some changes were made in 1.7 to reduce the amount of
> >> > unnecessary subtree-mergeinfo changes [2].
> >> >
> >> > [1] https://www.open.collab.net/community/subversion/articles/merge-info.html
> >> > [2] http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
> >> >
> >> > --
> >> > Johan
> >>
> >> Thank you. I don't mean updates to explicit mergeinfo, which I
> >> understand from 1.7 and prior, and I have read the docs on mergeinfo
> >> handling. In 1.8 and later I've started to see explicit svn:mergeinfo
> >> properties appearing on subtrees outside the context of user-initiated
> >> non-root merges and am trying to follow the circumstances in which
> >> they occur and whether I should stop being concerned about them.
> >>
> >> The earlier parts of this thread [1], where I was believing the new
> >> mergeinfo properties to be inadvertent (i.e., bugs) detail my
> >> confusion. I have stopped trying to tell the Subversion authors what
> >> I thought they meant to do :), and am now trying to get a solid
> >> understanding going forward.
> >>
> >> I (and others) had been inferring non-root merges when seeing explicit
> >> subtree mergeinfo (an inference informed by the articles that you
> >> cite), and believe on the basis of this thread that I have to stop
> >> doing that if I want to use 1.8 or newer. Because of the necessity to
> >> explain the rules to our developers, I was hoping for further
> >> clarification of those rules here.
> >>
> >
> > I think it's fairly accurate to say that a merge will only create/update
> > svn:mergeinfo on:
> >
> > 1. The merge target (i.e., usually the root of some branch).
> >
> > 2. Descendants of #1 that already have svn:mergeinfo properties.
> >
> > 3. Descendants of #1 that have a child or sibling that is switched or
> > excluded by authz (called "server-excluded" in the code) or excluded by
> > depth setting or not the same revision (in the 'svn info | grep
> > ^Revision:' sense) as its parent.
> >
> > Put another way, if you have a uniform-revision working copy with no
> > subtrees that are (switched or excluded-by-depth or server-excluded),
> > then svn:mergeinfo changes will only occur on the target root and on
> > files/dirs that already had svn:mergeinfo properties before the merge
> > started.
> >
> > Daniel
> >
> >> [1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260
> >>
> >> Thanks,
> >>
> >> --Pete
>
> That was my understanding also, but this isn't the behavior in 1.8
> (see this thread). I reported the change as a bug, but Subversion's
> maintainers say that the new behavior is normal (which is what this
> thread has been about). Hence my attempt to clarify what the rules
> are, or whether I need to stop caring about explicit mergeinfo (or
> stay with 1.7).
Will Subversion ever behave differently if the explicit svn:mergeinfo is
removed before the merge is committed, compared to how it would behave
if the explicit svn:mergeinfo were retained?
In my opinion, if the answer is "No", then having that explicit
svn:mergeinfo is a bug. Possibly a "wrong data is recorded" bug, but at
least a usability bug, due to how existence of explicit svn:mergeinfo
spams 'svn log -qv' of every merge commit down the road.
In the case of your script upthread, even if I add a 'svn merge
^/trunk/dir dir', I get mergeinfo of
branch - trunk:2-4
branch/dir - trunk/dir:4
and now the question is, effectively, "Is mergeinfo of trunk/dir:2-3 on
branch/dir a no-op for future merges". (Keeping in mind that trunk/dir
didn't even exist at r2.)
Unfortunately, I don't know the answer to that.
Daniel
Received on 2015-03-30 17:55:34 CEST