On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf <d...@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 <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
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).