Steve Stevenson writes:
>
> I am running CVS-1.10.8 and I am using Client/Server via pserver method.
> Looks like what happened is this. I had originally duped the code over the
> network through a Samba Server to a shared directory. I then took and
> imported it to the CVS Server on that system.
That was the fatal mistake -- when you import DOS/Windows text files on
a Unix-like machine, there's no way for CVS to know that it needs to do
anything with the line endings. So, you now have files in the
repository with <CR><LF> at the end of each line instead of just <LF>
like they should have.
> I then go to my nt machine
> login and checkout the files
And CVS dutifully converts each <LF> to <CR><LF>, so now each line ends
with <CR><CR><LF> which VC then converts to <CR><LF><CR><LF>.
> I did an experiment and actually imported
> from a NT machine to the Linux Server box and Did another checkout seems
> this worked okay my LF prob goes away doing it that way.
That's how you should do things -- when you import/check-in on NT, CVS
converts the line endings to a canonical form and vice versa on
check-out.
> But what happens if
> there is code to be shared both on NT and Unix. The linefeeds coming from
> any Unix edited code would cause double spaced lines in Visual c++. Was
> wondering if there was anyway around this.
As long as you don't try to share a working directory between different
types of systems, everything works -- CVS converts the line endings on
check-in/check-out correctly. What caused your problem was trying to
share a working directory between different systems and thus subverting
the automatic conversion. It's not the <LF>s in the Unix code that's
causing the problem, it's the <CR>s that shouldn't have been there in
the first place.
-Larry Jones
Hmm... That might not be politic. -- Calvin
