On Sat, Apr 13, 2013 at 3:23 PM, Daniel Shahaf <d...@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 <jcor...@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.ja...@gmail.com> >> > wrote: >> >> On Fri, Apr 12, 2013 at 9:27 PM, Ryan Schmidt >> >> <subversion-20...@ryandesign.com> wrote: >> >>> >> >>> >> >>> On Apr 12, 2013, at 11:35, James Marcus <marcus.ja...@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
