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/24 16:58:16 UTC

mergeinfo-normalizer issue with irrelevant ranges

Hi,

hope it's ok to discuss this on this list rather than the users list 
(since the tool is not part of a released version):

I'm looking at the following output from mergeinfo-normalizer analyse:

Trying to elide mergeinfo from path
     E:/[projects]/XR/clean_source_branch/src/SDKs/libVMM
     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/libVMM
         revisions missing in sub-node: 
191090,191096,191235,191239,191241,191243,191397,191459,191461-191462,191464,191467-191470,191615,191717-191718,193849,194280
     CANNOT elide branch /XRebirth/branches/XR_porting/src/SDKs/libVMM
         revisions missing in sub-node: 194976

     Branches not mentioned in parent:
     /SDKs/libVMM/trunk
     /SDKs/libVMM/tags/rev17
     /SDKs/libVMM/tags/rev18

     Sub-tree merge info cannot be elided due to the following branches:
     /SDKs/libVMM/trunk
     /XRebirth/branches/XR_porting/src/SDKs/libVMM
     /SDKs/libVMM/tags/rev17
     /SDKs/libVMM/tags/rev18
     /XRebirth/trunk/src/SDKs/libVMM


I don't quite understand why it thinks that these revisions are missing 
in the sub-node. Attached is the log-output I'm getting for revision 
191090. As far as I see this is completely independant from 
src/SDKs/libVMM and shouldn't be required at all... Am I wrong? (aka: 
all changes in that commit are under src/FOO/xxx which is different from 
src/SDKs)

Regards,
Stefan

Re: mergeinfo-normalizer issue with irrelevant ranges

Posted by Stefan Hett <st...@egosoft.com>.
Hi
> On Wed, Jun 24, 2015 at 4:58 PM, Stefan Hett <stefan@egosoft.com 
> <ma...@egosoft.com>> wrote:
>
>     Hi,
>
>     hope it's ok to discuss this on this list rather than the users
>     list (since the tool is not part of a released version):
>
>     I'm looking at the following output from mergeinfo-normalizer analyse:
>
>     Trying to elide mergeinfo from path
>         E:/[projects]/XR/clean_source_branch/src/SDKs/libVMM
>         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/libVMM
>             revisions missing in sub-node:
>     191090,191096,191235,191239,191241,191243,191397,191459,191461-191462,191464,191467-191470,191615,191717-191718,193849,194280
>         CANNOT elide branch /XRebirth/branches/XR_porting/src/SDKs/libVMM
>             revisions missing in sub-node: 194976
>
>         Branches not mentioned in parent:
>         /SDKs/libVMM/trunk
>         /SDKs/libVMM/tags/rev17
>         /SDKs/libVMM/tags/rev18
>
>         Sub-tree merge info cannot be elided due to the following
>     branches:
>         /SDKs/libVMM/trunk
>         /XRebirth/branches/XR_porting/src/SDKs/libVMM
>         /SDKs/libVMM/tags/rev17
>         /SDKs/libVMM/tags/rev18
>         /XRebirth/trunk/src/SDKs/libVMM
>
>
>     I don't quite understand why it thinks that these revisions are
>     missing in the sub-node. Attached is the log-output I'm getting
>     for revision 191090. As far as I see this is completely
>     independant from src/SDKs/libVMM and shouldn't be required at
>     all... Am I wrong? (aka: all changes in that commit are under
>     src/FOO/xxx which is different from src/SDKs)
>
>
> Thanks for the report. Turns out that changes
> to some parent path (e.g. /XRebirth/trunk/src)
> were wrongly considered relevant.
>
> Should be fixed in r1687317.
>
> -- Stefan^2.
Tested and can confirm it is fixed with the latest changes.

Thanks.

Regards,
Stefan

Re: mergeinfo-normalizer issue with irrelevant ranges

Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Wed, Jun 24, 2015 at 4:58 PM, Stefan Hett <st...@egosoft.com> wrote:

> Hi,
>
> hope it's ok to discuss this on this list rather than the users list
> (since the tool is not part of a released version):
>
> I'm looking at the following output from mergeinfo-normalizer analyse:
>
> Trying to elide mergeinfo from path
>     E:/[projects]/XR/clean_source_branch/src/SDKs/libVMM
>     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/libVMM
>         revisions missing in sub-node:
> 191090,191096,191235,191239,191241,191243,191397,191459,191461-191462,191464,191467-191470,191615,191717-191718,193849,194280
>     CANNOT elide branch /XRebirth/branches/XR_porting/src/SDKs/libVMM
>         revisions missing in sub-node: 194976
>
>     Branches not mentioned in parent:
>     /SDKs/libVMM/trunk
>     /SDKs/libVMM/tags/rev17
>     /SDKs/libVMM/tags/rev18
>
>     Sub-tree merge info cannot be elided due to the following branches:
>     /SDKs/libVMM/trunk
>     /XRebirth/branches/XR_porting/src/SDKs/libVMM
>     /SDKs/libVMM/tags/rev17
>     /SDKs/libVMM/tags/rev18
>     /XRebirth/trunk/src/SDKs/libVMM
>
>
> I don't quite understand why it thinks that these revisions are missing in
> the sub-node. Attached is the log-output I'm getting for revision 191090.
> As far as I see this is completely independant from src/SDKs/libVMM and
> shouldn't be required at all... Am I wrong? (aka: all changes in that
> commit are under src/FOO/xxx which is different from src/SDKs)
>

Thanks for the report. Turns out that changes
to some parent path (e.g. /XRebirth/trunk/src)
were wrongly considered relevant.

Should be fixed in r1687317.

-- Stefan^2.