[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs

From: Pete Harlan <pchpublic88_at_gmail.com>
Date: Fri, 27 Mar 2015 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.

[1] http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260

Thanks,

--Pete
Received on 2015-03-27 23:23:31 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.