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

Re: svn-mergeinfo-normalizer ideas

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Mon, 17 Aug 2015 00:35:34 +0100

On Fri, Jul 10, 2015 at 12:40 AM, Stefan Fuhrmann <
stefan.fuhrmann_at_wandisco.com> wrote:

> On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <stefan_at_egosoft.com> wrote:
>
>> Hi,
>>
>> I'm dealing with one remaining case svn-mergeinfo-normalizer normalize
>> doesn't seem to be able to handle yet. Would it be possible to add support
>> for this?
>>
>> Case: Eliminate incorrect mergeinfos of pre-branch-revisions.
>>
>> Looking at the following output:
>> Trying to elide mergeinfo from path
>> E:/[projects]/XR/clean_source_branch/src/SDKs/bullet
>> into mergeinfo at path
>> E:/[projects]/XR/clean_source_branch/src
>>
>> All branches still exist in HEAD.
>>
>> Try to elide remaining branches:
>> CANNOT elide branch /XRebirth/trunk/src/SDKs/bullet
>> revisions not movable to parent: 173817,174057,180942,181150
>>
>> Branches not mentioned in parent:
>> /SDKs/BulletPhysics/tags/2.82
>> /SDKs/BulletPhysics/trunk
>>
>> Sub-tree merge info cannot be elided due to the following branches:
>> /SDKs/BulletPhysics/tags/2.82
>> /SDKs/BulletPhysics/trunk
>> /XRebirth/trunk/src/SDKs/bullet
>>
>> here you see that the revisions 173817,174057,180942,181150 are reported
>> to not be movable to the parent.
>>
>> The thing here is that all of these revisions are effectively referencing
>> themselves and therefore should be removable in principle.
>>
>> The WC is a check-out of
>> repo
>> \proj1
>> \branches
>> \proj1v1
>>
>> The proj1v1 branch was created in revision 184223 from trunk - aka from:
>> repo
>> \proj1
>> \trunk
>>
>> so all the revisions (173817,174057,180942,181150) are referring to the
>> same thing which is implicitly included in the branch (due to its creation
>> from trunk at r184223). So these should simply be eliminated, no?
>>
>
> Yes, for all paths, their natural history can be considered being an
> implicit
> part of their merge history, i.e. "they contain all their own changes".
> Hence,
> they can't be actually missing and the branch entry in your example should
> be removed from the mergeinfo.
>
> To do this efficiently requires a fair amount coding, though. I'll give it
> a try.
>

The tool is on /trunk now and will detect overlapping "natural path
history".

-- Stefan^2.
Received on 2015-08-17 01:35:57 CEST

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

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