subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Date Sun, 29 Mar 2015 07:00:15 GMT
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@gmail.com> wrote:
> > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pchpublic88@gmail.com> wrote:
> >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pchpublic88@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

Mime
View raw message