[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 Hett <stefan_at_egosoft.com>
Date: Tue, 25 Aug 2015 14:11:37 +0200

Hi,
> On Fri, Jul 10, 2015 at 12:40 AM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com <mailto:stefan.fuhrmann_at_wandisco.com>>
> wrote:
>
> On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <stefan_at_egosoft.com
> <mailto: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.
>
Thanks so much. Just tested it and it works like a charm.

-- 
Regards,
Stefan Hett
Received on 2015-08-25 14:12:01 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.