On Sun, Mar 29, 2015 at 12:00 AM, Daniel Shahaf <d.s_at_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 <jcorvel_at_gmail.com> wrote:
>> > 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
>>
>> 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).
Received on 2015-03-30 17:43:30 CEST