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