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...@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).
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