Pete Harlan wrote on Fri, Mar 27, 2015 at 15:22:16 -0700: > On Fri, Mar 27, 2015 at 2:27 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > > On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pchpubli...@gmail.com> wrote: > >> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pchpubli...@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
