Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 15:59:17 +0300:
> Fri, 22 Apr 2011 15:29:04 +0300, /Daniel Shahaf/:
> >Stanimir Stamenkov wrote on Fri, Apr 22, 2011 at 14:36:53 +0300:
> >
> >>Is anyone aware of repository dump filter [1] which corrects the EOL
> >
> >Not me, but sounds like a one-off patch (to the "Create a new file"
> >logics of 'load' or 'svnsync') could do this pretty easily.
> >
> >(Insert here quote about, given a hammer, viewing every problem as a nail.)
> >
> >As you may know: if a file has uniform line endings, svn canonicalizes
> >them when the property is set. (though I don't remember if that's done
> >on the server-side too, or only on the client side)
>
> Yep, I'm aware of this, but then I aim at correcting the history
> when svn:eol-style property has not been properly set already with
> adding the file(s), which becomes a problem (or at least not small
> inconvenience) when the file has been initially created on Windows
> with non-repository-native EOL style, or just the EOL style has been
> inadvertently changed before the svn:eol-style gets properly set.
> This situation is caused by user ignorance one cannot always
> control. Commit hooks can help but they are not part of the default
> setup, also.
>
Right; if, for example, you apply 'native' EOL, it would convert the
file to LF internally, and any subsequent text deltas wouldn't apply as
intended.
So I'd go for svnsync; it has access to the full 'original' history,
which 'svnadmin load' hasn't. It should be possible to patch svnsync
into generating the correct text-deltas for files whose properties have
been mangled --- for example, if you've set a property to 'native', then
have svnsync compute not the text delta between rN-1 and rN, but between
convert_to_LF(rN-1) and convert_to_LF(rN).
There may well be a simpler solution that I'm overlooking.
> --
> Stanimir
Received on 2011-04-22 15:22:20 CEST