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
Received on 2015-03-29 09:00:48 CEST