svn:eol-style flaw (was Re: Subversion migration in progress: CVS is now read-only)

[Hans Breuer <hans breuer org>]

On 16.07.2006 05:10, Ross Golder wrote:
> On ส., 2006-07-15 at 17:31 +0200, Hans Breuer wrote:
[...]
> > While tracking progress with an svn client I noticed the following 
> > problem: 	svn:eol-style = native
> > is not set anymore, at least not on glib.
> >
> > With my test checkout of dia from February it worked as expected, that
> > system native line endings where preserved as they were in cvs.
> >
> > Is this a matter of a conversion script change or will there be an extra
> > step following to make checkout from non-unix sueable again?
>
> We had to stop cvs2svn from guessing the 'svn:eol-style' using it's own
> algorithm, as it was getting a lot of false positives. Particularly, it
> was corrupting binary files (e.g. PNGs/WAVs). 
Getting broken PNGs from cvs is/was quite common on windows. But the fix 
with CVS is easy: 'cvs admin -kb *.png'. AFAIK this changes the 
representation of PNG to binary throug all existing versions.

This would not be the case for SVN, because it is tracking history for the 
meta-data as well. So the versions before setting 'svn:eol-style = native'
would remain broken.

> Unfortunately, we only
> noticed this 8-9 hours after we'd started the migration, so we had to
> restart the migration again using cvs2svn's '--no-default-eol-style'
> option. Unfortunately, it seems to have had the knock-on effect you've
> described.
Looks like '--eol-from-mime-type' should have been added to the script as 
well. Though the outcome for files like 'ChangeLog', i.e. without extension
would be interesting.

Without diving too deep into cvs2svn I would expect it to respect the
binary state given in cvs. In any case not having set binary for
PNGs and WAVs is a bug in cvs usage; fixing this by the conversion
script looks like a lame work-around.

> As this is the second problem with the migration we've had since
> cut-off, we've decided to cancel the migration for now pending some
> further testing. With the exception of a couple of modules which had
> already taken commits in subversion, I'll be re-enabling write access to
> CVS shortly. I'll post a list of the modules that will remain in
> Subversion.
Because you were mentioning PNG and WAV I've just looked at beast/cvs and 
in fact it has not set the binary flag correctly for PNG. Though I did not 
find any WAVs there.

I'd propose to drop the --no-default-eol-style again (non binary files are 
much more common in a source code version system) but add 
--eol-from-mime-type (so default-eol-style becomes the fallback).

Also the modules with known good binary state should be upped in conversion 
priority, respectively the "known bad" modules should be removed from the 
list until they are fixed.

From my perspective the "known good" modules are the ones with mature 
win32 ports: dia and gimp including their dependencies (glib, pango, atk, 
gtk+, gnome-xml, ...).

Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert