On Fri, Mar 27, 2015 at 9:01 PM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
> On Tue, Mar 24, 2015 at 11:24 AM, Pete Harlan <pchpublic88_at_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
Received on 2015-03-27 22:28:13 CET