On Sat, Apr 13, 2013 at 3:23 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Sat, Apr 13, 2013 at 09:41:46 +0200:
>> On Sat, Apr 13, 2013 at 9:38 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> > [ Please don't top-post on this list, i.e. put your reply at the
>> > bottom or inline, thanks. More below. ]
>> >
>> > On Sat, Apr 13, 2013 at 6:08 AM, James Marcus <marcus.james_at_gmail.com> wrote:
>> >> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt
>> >> <subversion-2012c_at_ryandesign.com> wrote:
>> >>>
>> >>>
>> >>> On Apr 12, 2013, at 11:35, James Marcus <marcus.james_at_gmail.com> wrote:
>> >>>
>> >>> > I actually started a migration with svnsync so that I didn't have to
>> >>> > worry about network issues related to transferring a single 36GB file on an
>> >>> > unreliable network. But I ran into this issue: Cannot accept non-LF line
>> >>> > endings in 'svn:log' property [500, #125005]
>> >>> >
>> >>>
>> >>> You should fix the svn:log property of that revision so that it does not
>> >>> contain non-LF line endings.
>> >>>
>> >> I did fix it, but there are many, how do you deal with hundreds maybe
>> >> thousands?
>> >
>> > I believe svnadmin dump/load (with 1.7) fixes those automatically. So
>> > one option is to use that (or to use those to create an intermediate
>> > repository which you can then transfer with svnsync). Or repair the
>> > svn:log properties in the source repository with some script.
>> >
>> > HTH
>> > --
>> > Johan
>>
>> Ah, and perhaps svnrdump also works. Not sure, you'll have to test it
>> (or perhaps someone else on this list knows ...).
>
> The LF check happens in the repos layer, but 'svnadmin load' uses the FS
> API directly so it doesn't trip that check. svnsync can't do this so
> I think it has a (half-supported?) flag to auto-fix non-LF svn:*
> properties.
Ah, I thought I remembered that I got them auto-repaired when I did an
svnadmin dump + load (with 1.7.x), but I'm not sure anymore (it was
with a test migration a year ago).
> As an aside, has anyone mentioned the authz + svnsync approach to
> filtering history (as opposed to svnrdump | svndumpfilter) in this
> thread yet?
Ah yes, good suggestion (if the OP finds a way to repair his log
entries, or a way to let svnsync accept them).
James, you may want to search the list archives a bit for this:
basically, if you set up path-based authz for the "svnsync user", and
deny the svnsync user access to the paths you want to filter out,
that's also a way to create a copy of your repository minus the paths
you don't want.
But remember what Thorsten said: you're creating a new repository,
with a "new history", so it must have another UUID than the original,
and existing working copies need to be discarded ... everyone needs to
get a new checkout.
--
Johan
Received on 2013-04-14 00:46:28 CEST