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
