NTEmacs, CVS, PCL-CVS, Version Control and ^M?

NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Galen Boyer]

We have a CVS server on a UNIX machine but, AFAIK, most of us are
committing our work from Windows machines.  But, we also have a mix of
people using WINCVS and cygwin CVS command-line.  I and the other cygwin
users will also use WinCVS on and off as well, so this may be causing
issues?  I use PCL-CVS for most of my day-to-day CVS work.  (The
.cvspass will get munged every once in awhile because of these switch
offs) What seems to be happening, but I can't quite find the pattern is
that more than one ^M will get appended to the end of the files so then
the ^M's show up, no matter what how I ask Emacs to handle the ^M,
because there is more than one.

What I'd like to know is if anybody has any experience with odd behavior
from checking in and checking out code and windows/UNIX end-of-line
characters getting inserted.  Its driving us a little nutty and we
aren't quite sure how to figure out what is truly happening.  Right now
we are removing the ^M manually (well Emacs manually anyways).

Thanks.
-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Eli Zaretskii]

> From: Galen Boyer <galenboyer@hotpop.com>
> Newsgroups: gnu.emacs.help
> Date: 23 Apr 2003 20:56:09 -0500
> 
> What I'd like to know is if anybody has any experience with odd behavior
> from checking in and checking out code and windows/UNIX end-of-line
> characters getting inserted.

You are in for some annoying work, so get ready.  Each Windows CVS
client has its own quirks as to the end-of-line (EOL) handling.  Some
have options to do different things to the EOL characters, others
don't.  Some, like the Cygwin's one, depend on how the volume was
``mounted'' (text or binary).  The only way I know of to fight this
insanity is to find the correct procedure for each CVS client and
educate the users to use that procedure.

You will need to study each client's docs, find out what facilities
does it have, agree on the best (i.e. simplest and most reliable)
method of using those facilities, then publish a document with
instructions for each client.  If you can get your users to switch
clients (assuming there's some client that makes this issue a simple
one), then do that as well.

A complication is that some Windows editors don't cope well with files
that have Unix-style newline-only EOLS.  If you all are using Emacs,
this is not a problem, but if some of you don't, they might need to
make sure text files are converted to DOS-style CR-LF EOLs.

Another related issue is how to create Unix-style files on Windows.
For that, you can use the untranslated-filesystem feature of Emacs,
described in the manual.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Jason Rumney]

Galen Boyer <galenboyer@hotpop.com> writes:

> We have a CVS server on a UNIX machine but, AFAIK, most of us are
> committing our work from Windows machines.  But, we also have a mix of
> people using WINCVS and cygwin CVS command-line.

I guess these people are the cause of the problem, since cygwin CVS
and WinCVS treat line-ends differently. If you use a mixture of them,
then you will get strange line ends in your files.

It is better to use the command-line CVS that comes with WinCVS if
you will be using WinCVS.

> What I'd like to know is if anybody has any experience with odd behavior
> from checking in and checking out code and windows/UNIX end-of-line
> characters getting inserted.  Its driving us a little nutty and we
> aren't quite sure how to figure out what is truly happening.  Right now
> we are removing the ^M manually (well Emacs manually anyways).

I have seen another problem, when checkins are done from Emacs, and
you have $Log: $ lines in your source file, then multi-line comments
can end up with DOS line ends even when the file being checked in has
Unix line ends. I haven't worked out if this is an Emacs problem or
WinCVS one.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Phillip Lord]

>>>>> "Galen" == Galen Boyer <galenboyer@hotpop.com> writes:

  Galen> We have a CVS server on a UNIX machine but, AFAIK, most of us
  Galen> are committing our work from Windows machines.  But, we also
  Galen> have a mix of people using WINCVS and cygwin CVS
  Galen> command-line.  I and the other cygwin users will also use
  Galen> WinCVS on and off as well, so this may be causing issues?  I
  Galen> use PCL-CVS for most of my day-to-day CVS work.  (The
  Galen> .cvspass will get munged every once in awhile because of
  Galen> these switch offs) What seems to be happening, but I can't
  Galen> quite find the pattern is that more than one ^M will get
  Galen> appended to the end of the files so then the ^M's show up, no
  Galen> matter what how I ask Emacs to handle the ^M, because there
  Galen> is more than one.


If you try and use more than one client, then you are likely to get
into trouble. So, for instance, using both a unix client, and a
wincvs client on the same files will result in line terminator
problems. 

You could put a check script into the CVS. Essentially any windows
terminators in the repository are wrong (in a text file obviously). 



  Galen> What I'd like to know is if anybody has any experience with
  Galen> odd behavior from checking in and checking out code and
  Galen> windows/UNIX end-of-line characters getting inserted.  Its
  Galen> driving us a little nutty and we aren't quite sure how to
  Galen> figure out what is truly happening.  Right now we are
  Galen> removing the ^M manually (well Emacs manually anyways).

Most of the people here are using one client only, and although we
have had some problems it generally works. All the Windows emacs users
use dos terminators all the time, even with cygwin CVS.

Good luck.

Phil

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Eli Zaretskii]

> From: Phillip Lord <p.lord@russet.org.uk>
> Newsgroups: gnu.emacs.help
> Date: 24 Apr 2003 10:33:26 +0100
> 
> If you try and use more than one client, then you are likely to get
> into trouble. So, for instance, using both a unix client, and a
> wincvs client on the same files will result in line terminator
> problems.

I really don't know why did you say that.  For example, Emacs
developers use both Unix and Windows CVS clients, and several
varieties of the Windows ones at that, and I have yet to see any
significant problems with the files in the repository.  In fact, I
cannot recall even a single problem related to that; all source files
are kept in the repository in their original Unix EOL format.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Jason Rumney]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > From: Phillip Lord <p.lord@russet.org.uk>
> >
> > If you try and use more than one client, then you are likely to get
> > into trouble. So, for instance, using both a unix client, and a
> > wincvs client on the same files will result in line terminator
> > problems.
> 
> I really don't know why did you say that.  For example, Emacs
> developers use both Unix and Windows CVS clients

That is on different working copies of the files. The problem comes
when you use a different client to checkin than the one that was used
to checkout.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Phillip Lord]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

  >> From: Phillip Lord <p.lord@russet.org.uk> Newsgroups:
  >> gnu.emacs.help Date: 24 Apr 2003 10:33:26 +0100
  >>
  >> If you try and use more than one client, then you are likely to
  >> get into trouble. So, for instance, using both a unix client, and
  >> a wincvs client on the same files will result in line terminator
  >> problems.

  Eli> I really don't know why did you say that.  For example, Emacs
  Eli> developers use both Unix and Windows CVS clients, and several
  Eli> varieties of the Windows ones at that, and I have yet to see
  Eli> any significant problems with the files in the repository.  In
  Eli> fact, I cannot recall even a single problem related to that;
  Eli> all source files are kept in the repository in their original
  Eli> Unix EOL format.


On the same files? I should be clear here, when I say "files" I mean
work files, not a repository file. 

For instance, if you have a file space shared between windows and a
unix box. Then you check out a module using the unix CVS (the workfile
versions will then have unix terminators). And then you operate over
those files using the windows client, and check them in? The windows
client is expecting dos terminators. What will happen? Well I'm not
sure. 

Like wise if you go the other way around, and check out with a windows
client, and then checkin with a unix client? I am pretty sure that the
unix client will not translate out the dos terminators, because its
not expecting them in the first place. And so you will end up with dos
terminators in the repository, at which point it all goes pear
shaped. 

Now there are other problems besides this. I checked out a file from
CVS yesterday, under unix, and the resultant file had dos
terminators. 

These problems can be avoided. I think the situation you are
describing is where each developer uses only one client, although this
may be a different client in each case. I agree this can work, without
problems, although it does not always. 

In summary, if you operate on the same work files, with a windows, and
unix client, you are almost certain to end up with line terminator
problems. If each developer has only one client each, then you should
not have problems, although an occasional difficulty may occur. 

This is my experience anyway. 

Phil

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Eli Zaretskii]

> From: Phillip Lord <p.lord@russet.org.uk>
> Newsgroups: gnu.emacs.help
> Date: 25 Apr 2003 12:43:23 +0100
> 
>   Eli> I really don't know why did you say that.  For example, Emacs
>   Eli> developers use both Unix and Windows CVS clients, and several
>   Eli> varieties of the Windows ones at that, and I have yet to see
>   Eli> any significant problems with the files in the repository.  In
>   Eli> fact, I cannot recall even a single problem related to that;
>   Eli> all source files are kept in the repository in their original
>   Eli> Unix EOL format.
> 
> 
> On the same files? I should be clear here, when I say "files" I mean
> work files, not a repository file. 
> 
> For instance, if you have a file space shared between windows and a
> unix box. Then you check out a module using the unix CVS (the workfile
> versions will then have unix terminators). And then you operate over
> those files using the windows client, and check them in? The windows
> client is expecting dos terminators. What will happen? Well I'm not
> sure. 

Most, if not all, of Windows CVS clients work just fine with
Unix-style EOLs.  When you checkin such files, what you get in the
repository is Unix EOLs.

Thus, if the issue of editing the same files from Windows and Unix
machines is solved, the issues with CVS should not be a problem.

The issue of editing the same files from Windows and Unix machines is
not really related to what we were talking about, but if Emacs is used
on all the machines, it is solved almost by default--the only
non-default setting is a proper definition of untranslated
filesystems, as I wrote elsewhere in this thread.

> Like wise if you go the other way around, and check out with a windows
> client, and then checkin with a unix client? I am pretty sure that the
> unix client will not translate out the dos terminators, because its
> not expecting them in the first place.

Right.  And that's why the procedure(s) I was talking about in my mail
should make sure files are checked out with Unix EOLs, even on
Windows.

> Now there are other problems besides this. I checked out a file from
> CVS yesterday, under unix, and the resultant file had dos
> terminators. 

You should ideally have your CVS setup in such a way that this does
not happen.  A Unix-EOL file should be checked out into a workfile
with with Unix EOLs.  If worse comes to worst, there are programs to
convert between the EOL formats without changing the file's timestamp.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Phillip Lord]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

  >> From: Phillip Lord <p.lord@russet.org.uk> Newsgroups:
  >> gnu.emacs.help Date: 25 Apr 2003 12:43:23 +0100
  >>
  Eli> I really don't know why did you say that.  For example, Emacs
  Eli> developers use both Unix and Windows CVS clients
  >>
  >> On the same files? I should be clear here, when I say "files" I
  >> mean work files, not a repository file.
 

  Eli> Most, if not all, of Windows CVS clients work just fine with
  Eli> Unix-style EOLs.  When you checkin such files, what you get in
  Eli> the repository is Unix EOLs.

Maybe. All I can say is that I have seen problems with some clients
checking in dos terminated files. Mostly this seems to come from
windows boxes. 


  Eli> The issue of editing the same files from Windows and Unix
  Eli> machines is not really related to what we were talking about,
  Eli> but if Emacs is used on all the machines, it is solved almost
  Eli> by default--the only non-default setting is a proper definition
  Eli> of untranslated filesystems, as I wrote elsewhere in this
  Eli> thread.

Indeed, getting untranslated filesystems right helps a lot. 


  >> Now there are other problems besides this. I checked out a file
  >> from CVS yesterday, under unix, and the resultant file had dos
  >> terminators.

  Eli> You should ideally have your CVS setup in such a way that this
  Eli> does not happen.  A Unix-EOL file should be checked out into a
  Eli> workfile with with Unix EOLs.  If worse comes to worst, there
  Eli> are programs to convert between the EOL formats without
  Eli> changing the file's timestamp.

The fundamental difficulty, is I think, that there are so many
possible combinations of tools. I use emacs, on unix, with
vc/pcl-cvs. Others use emacs, on windows, and WinCVS for all their
versioning. Others use emacs, on windows, cygwin cvs. And others, of
course, do not use emacs at all, god rest their souls. 

Ideally you are right, CVS should be setup so that EOL terminators are
not a problem. But this is not the ideal world, and I have found
recurrent problems with this. And sometimes inconsistent problems. I
still find that, occasionally, DOS terminators turn up. Sometimes on
the entire file (in which case emacs handles it gracefully, with just
a "DOS" sign at the bottom), and other times in just part of the file
(in which case you get Ctrl-M's appearing). From hanging around on the
cvs newsgroup for a while, I see that others have problems also.

I'm just relating my experience. I generally find that getting it all
working is manageable, but not entirely transparent (with emacs, or
without!). Galen, it would appear, has found a similar thing.

Phil

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Eli Zaretskii]

> From: Phillip Lord <p.lord@russet.org.uk>
> Newsgroups: gnu.emacs.help
> Date: 25 Apr 2003 16:43:43 +0100
> 
> The fundamental difficulty, is I think, that there are so many
> possible combinations of tools.

Right, that's what I wrote in my message as well.

> I'm just relating my experience.

Sure, I don't intend to argue with your experience.  I think we
basically agree that setting this up is not easy, we just might
disagree a bit about how hard is it.

Re: NTEmacs, CVS, PCL-CVS, Version Control and ^M?

[Phillip Lord]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

  >> From: Phillip Lord <p.lord@russet.org.uk> Newsgroups:
  >> gnu.emacs.help Date: 25 Apr 2003 16:43:43 +0100
  >>
  >> The fundamental difficulty, is I think, that there are so many
  >> possible combinations of tools.

  Eli> Right, that's what I wrote in my message as well.

And I in mine!

  >> I'm just relating my experience.

  Eli> Sure, I don't intend to argue with your experience.  I think we
  Eli> basically agree that setting this up is not easy, we just might
  Eli> disagree a bit about how hard is it.

Now that I know most of the pitfalls, its generally not too hard. I
seem to remember discovering the pitfalls was a pain though, and I
still haven't got through all of them I am sure. 

Cheers

Phil