>Now that I understand what the problem is, I'd like some advice on how
>to resolve it. It appears that the problem was caused by cvs2svn,
>which imported Windows-formatted files with the svn:eol-style property
>set but without normalising the endlines in the files themselves. This
>affects all windows-formatted files in the system (primarily
>What I'm looking for is a way to correct the whole lot and commit the
>fix in one big changeset. That will result in loads of conflicts in
>the next few branch merges, but would fix the problem once and for all
>going forward. The question is, how to do that. svn doesn't want to
>commit the file unless the file gets changed, so I suspect that I'd
>have to change the files in some way (though that is hardly ideal).
>Anything else I can try?
>The other problem is how to detect the problem files. The only way I
>can think of is to look for all files that are Windows-formatted, have
>the svn:eol-style property set to native, and haven't been changed
>since the subversion import. Doesn't sound like a quick method (and
>I'm not aware of a command-line utility to check for windows format).
>Does anybody else have any suggestions?
I have the same problem, at the time the SVN client (1.0.6, I think) let me
fix the files on the trunk by removing the property, fixing the file and
setting the property again. But later clients seem to have become more
strict about how they treat the inconsistencies and stop when they hit the
The problem today is usually when looking back in the history of the file,
is not possible to retrieve the old revision or diff against it to see what
My thought is that is should be possible to dump the repository and check
for files with the property set but with lines that aren't normalized, then
create a new dump file with the repaired files and load that as the new
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jun 1 14:30:13 2005