Re: svn-mergeinfo-normalizer ideas

[Stefan Hett]

Hi,

On Fri, Jul 10, 2015 at 12:40 AM, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com <mailto:stefan.fuhrm...@wandisco.com>> wrote:

    On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett <ste...@egosoft.com
    <mailto:ste...@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