You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Hett <st...@egosoft.com> on 2015/06/25 17:10:26 UTC
svn-mergeinfo-normalizer ideas
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?
Regards,
Stefan
Re: svn-mergeinfo-normalizer ideas
Posted by Stefan Hett <st...@egosoft.com>.
Hi,
> On Fri, Jul 10, 2015 at 12:40 AM, Stefan Fuhrmann
> <stefan.fuhrmann@wandisco.com <ma...@wandisco.com>>
> wrote:
>
> On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <stefan@egosoft.com
> <ma...@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
Re: svn-mergeinfo-normalizer ideas
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Jul 10, 2015 at 12:40 AM, Stefan Fuhrmann <
stefan.fuhrmann@wandisco.com> wrote:
> On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <st...@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.
Re: svn-mergeinfo-normalizer ideas
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <st...@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.
-- Stefan^2.