[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: cvs2svn and eol style

From: Nicklas Norling <nicklas.norling_at_ifsab.se>
Date: 2004-03-26 10:46:22 CET

> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net]
> Sent: den 26 mars 2004 10:23
> To: Nicklas Norling; users@cvs2svn.tigris.org
> Subject: Re: cvs2svn and eol style
> Nicklas Norling wrote:
> > Hi,
> >
> > Sorry to bother you again on this issue.
> > Ref. http://cvs2svn.tigris.org/issues/show_bug.cgi?id=26
> >
> > I looked into the mail around the patch and while I can see setting
> > all the imported svn:eol-style to native would solve my problem it
> > doesn't look like a clean solution to me.
> >
> > I've tried setting the property manually on a few files,
> and it does
> > indeed fix the problem on the client side. However, at least in my
> > mind, the problem is still unsolved on the server side. If
> I create a
> > new source code file on my windows machine and check it in
> it will get
> > no svn:eol-style property set but checking it out gives me
> the right
> > eol characters automatically.
> >
> > Looking at the svnbook a bit closer I find:
> > "Note that Subversion will actually store the file in the
> repository
> > using normalized LF EOL markers regardless of the operating system"
> >
> > Under the "native" section in
> > http://svnbook.red-bean.com/svnbook/ch07s02.html#svn-ch-7-sect-2.3.5
> >
> > If that is so, wouldn't that indicate that the actual file as
> > converted with cvs2svn has had it's content changed to now
> have unix
> > line endings in addition to the "normalized" line endings
> subversion
> > has? Looks to me that all text files in my subversion repo gets
> > altered in this way.
> >
> > Max wrote "...so the line endings remain in unix form",
> maybe what is
> > needed is to convert those unix line endings from the cvs
> storage to
> > Subversions "normalized" line endings?
> Subversion's normalized line endings *are* unix line endings.
> > I really feel this ought to work out of the box somehow.
> Especially as
> > this ought to be a common problems where windows users use
> subversion.
> >
> > Or am I totally off here? Not grasping the whole picture maybe.
> The fact that you *have* to set eol-style to get eol
> translation is a deliberate design decision, due to the fact
> that a common complaint of Windows CVS users is "I checked in
> an image and it was corrupted" - because CVS eol-converted
> it. So subversion does things the other way around, and makes
> you say, "yes, I really do want this file eol-converted."

I'd say most windows CVS users use TCVS as it has such a compelling
UI and windows users tends to like that. I have not had any problem
with checking in files where TCVS did not figure out the correct
eol style. If a file ending is unknown it will ask me.

In my mind the design is taking a pretty rare case into account too
much. The result is that a conversion from cvs to subversion using
cvs2svn creates a repository that is not able to create a correct
wc on a windows machine per default.

Also one should take into account the horrid task to add svn:eol-style
to each and every text file in the converted repository. I know that
that is less of a hassle on a *nix machine where find grep etc. and
in existence, but in windows all I have is TSVN to manually change the
tens of thousands of files, making sure I only change the text based.

I'm about to convert our production cvs within days, I would have
hoped to be able to do this without svn:eol-style.

Is there any workarounds other then manually editing these files?
If I was able to setup a *nix machine, could I somehow do this more
automatically? Getting desperate here...

> Further discussion on svn:eol-style should be directed to
> users@subversion, not users@cvs2svn.
> Max.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 26 10:47:05 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.