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.
As an aside, has anyone mentioned the authz + svnsync approach to
filtering history (as opposed to svnrdump | svndumpfilter) in this
thread yet?
Received on 2013-04-13 15:24:33 CEST