> -----Original Message-----
> From: Max Bowsher [mailto:email@example.com]
> Sent: den 26 mars 2004 10:23
> To: Nicklas Norling; firstname.lastname@example.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
> > 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
> > 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
> > 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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Mar 26 10:47:05 2004