--normalize-probs doesn't do its thing

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

--normalize-probs doesn't do its thing

Thorsten Goetzke
Hello,

I am evaluating a migration for some very old repositories to subversion
1.10. These are currently running using subversion 1.7, but where most
likely created a much older version. I use the binaries provided by wandisco

svnadmin, version 1.10.3 (r1842928)

My current migration strategy is to apply a dump load cyrcle using the
current svnadmin tool
Seems to work most repositories but for one particualar theres a problem.

I am using svnadmin load --normalize-props uls/ -F ../uls.txt

And i get:
<<< Started new transaction, based on original revision 18083
      * editing path :
uls/trunk/uls/TestAutomation/UMS_Testmanagement/02_Implementation/java/TestManagementUI
...svnadmin: E125005: A property with invalid line ending found in
dumpstream; consider using --normalize-props while loading.

Are there some catches on how to use --normalize-probs?

Best regards,
Thorsten Goetzke
Reply | Threaded
Open this post in threaded view
|

Re: --normalize-probs doesn't do its thing

Daniel Shahaf-2
Thorsten Goetzke wrote on Tue, 26 Mar 2019 10:40 +00:00:

> Hello,
>
> I am evaluating a migration for some very old repositories to subversion
> 1.10. These are currently running using subversion 1.7, but where most
> likely created a much older version. I use the binaries provided by wandisco
>
> svnadmin, version 1.10.3 (r1842928)
>
> My current migration strategy is to apply a dump load cyrcle using the
> current svnadmin tool
> Seems to work most repositories but for one particualar theres a problem.
>
> I am using svnadmin load --normalize-props uls/ -F ../uls.txt
>
> And i get:
> <<< Started new transaction, based on original revision 18083
>       * editing path :
> uls/trunk/uls/TestAutomation/UMS_Testmanagement/02_Implementation/java/TestManagementUI
> ...svnadmin: E125005: A property with invalid line ending found in
> dumpstream; consider using --normalize-props while loading.

This error code is specifically caused by an svn:* property whose value
contains a CR byte (0x0D).  It could be either a revprop or a versioned
property.  In either case, --bypass-prop-validation should allow the
load to proceed (but the invalid data will remain in the history of the
new repository).

(We should make that error message show the name of the property,

> Are there some catches on how to use --normalize-probs?

Note that it's spelled "props" (short for "properties").
Reply | Threaded
Open this post in threaded view
|

Re: --normalize-props doesn't do its thing

Thorsten Goetzke
Hello,

svnadmin already reports the name of the property i just failed to copy
& paste the full message
svnadmin: E125005: Invalid property value
svnadmin: E125017: Cannot accept non-LF line endings in 'svn:ignore'
property

Well about --bypass-prop-validation.... i did just try that only to find
out that that starting with the offending commit (18083) all following
commits seem to not have not been applied to the target repository.

Next stop would be the dumptool, it seems like that offers something for
this non-LF thing as well
https://github.com/jwiegley/svndumptool

Best regards,
Thorsten Goetzke




Am 26.03.19 um 16:10 schrieb Daniel Shahaf:

> Thorsten Goetzke wrote on Tue, 26 Mar 2019 10:40 +00:00:
>> Hello,
>>
>> I am evaluating a migration for some very old repositories to subversion
>> 1.10. These are currently running using subversion 1.7, but where most
>> likely created a much older version. I use the binaries provided by wandisco
>>
>> svnadmin, version 1.10.3 (r1842928)
>>
>> My current migration strategy is to apply a dump load cyrcle using the
>> current svnadmin tool
>> Seems to work most repositories but for one particualar theres a problem.
>>
>> I am using svnadmin load --normalize-props uls/ -F ../uls.txt
>>
>> And i get:
>> <<< Started new transaction, based on original revision 18083
>>        * editing path :
>> uls/trunk/uls/TestAutomation/UMS_Testmanagement/02_Implementation/java/TestManagementUI
>> ...svnadmin: E125005: A property with invalid line ending found in
>> dumpstream; consider using --normalize-props while loading.
>
> This error code is specifically caused by an svn:* property whose value
> contains a CR byte (0x0D).  It could be either a revprop or a versioned
> property.  In either case, --bypass-prop-validation should allow the
> load to proceed (but the invalid data will remain in the history of the
> new repository).
>
> (We should make that error message show the name of the property,
>
>> Are there some catches on how to use --normalize-probs?
>
> Note that it's spelled "props" (short for "properties").
>
Reply | Threaded
Open this post in threaded view
|

Re: --normalize-probs doesn't do its thing

Evgeny Kotkov
In reply to this post by Thorsten Goetzke
Thorsten Goetzke <[hidden email]> writes:

> uls/trunk/uls/TestAutomation/UMS_Testmanagement/02_Implementation/java/TestManagementUI
> ...svnadmin: E125005: A property with invalid line ending found in
> dumpstream; consider using --normalize-props while loading.
>
> Are there some catches on how to use --normalize-probs?

Apparently, there is a bug in the implementation of --normalize-props
that only makes it automatically fix line endings in the values of the
revision properties, but not node properties (as per the code around
load-fs-vtable.c: set_node_property()).

I'll put fixing that on my TODO list.


Regards,
Evgeny Kotkov
Reply | Threaded
Open this post in threaded view
|

Re: --normalize-probs doesn't do its thing

Evgeny Kotkov
Evgeny Kotkov <[hidden email]> writes:

> Apparently, there is a bug in the implementation of --normalize-props
> that only makes it automatically fix line endings in the values of the
> revision properties, but not node properties (as per the code around
> load-fs-vtable.c: set_node_property()).

I think that this issue should be fixed by https://svn.apache.org/r1868203

(Will try to nominate this fix to the stable branches, once I get some spare
time for that.)


Regards,
Evgeny Kotkov