Just do a
tr -d \\r <old >new
I have a small script called dos2unix which does this for all files on the commandline.

It doesn't exacly comment it. It just puts markers: <<<<<<<
=======

>>>>>>

Just search for these, and edit as needed. You are warned if there are conflicts anyway...

If you are going to be doing editing it is always best to do an update just before you start to work so your source is as fresh as possible.

Correct, this is good practice.

Michael.

Michael A. Hess wrote

> I don't know if this is a result of some people editing in win32 Edit, > some in linux vi or emacs or whatever you guys use, That is what I assumed was doing it.

Sounds reasonable. It would be nice if it didn't happen though ;)

It attempts to merge the 2 files into one. If the changes you have made are too extensive for it to figure out itself it comments what is different between the 2 versions and lets you fix it up manually.

I think that is what is messing me up. I went in and cleaned out all of those extra $0D's out of the files in the lazarus directory, and apparently CVS considers whitespace significant, becuase what I got after update was not compileable. Lots of <<<<<<< and ======= all over the place, and it wasn't clear to me what was new and what was old. So I tried to clean that up, and things just got worse.

If you are going to be doing editing it is always best to do an update just before you start to work so your source is as fresh as possible.

That's the first thing I do when I get started on it. However, since I haven't done anything that anyone needs yet (trying to get familiar with it) and can't commit anyway, I am switching to doing a deltree on the lazarus directory and then checking out from scratch, so that I won't run into the problems described above. For just lazarus, it takes almost no time. I am staying out of the gtk, fcl, and rtl trees as far as editing goes, just reading those, so no problems with updates.

Jeff.

Jeffrey A. Wormsley wrote

I have a tiny issue that most of you probably haven't noticed.

I've noticed but wasn't sure what to do about it. In most cases it doesn't bother me except in one major case. If you try to use xxgdn to trace you program the debugger gets all wacked out if you have DOS EOLs in the content. Makes it a REAL pain. :-\

I don't know if this is a result of some people editing in win32 Edit, some in linux vi or emacs or whatever you guys use,

That is what I assumed was doing it.

On to the CVS questions. What does CVS do to a source file that I have editted, and it detects there is a new version to be downloaded?

It attempts to merge the 2 files into one. If the changes you have made are too extensive for it to figure out itself it comments what is different between the 2 versions and lets you fix it up manually.

If you are going to be doing editing it is always best to do an update just before you start to work so your source is as fresh as possible.

I have a tiny issue that most of you probably haven't noticed. A lot of the source files I am getting in from CVS updates have odd end of line terminations. It is neither *nix or dos standard, but instead seems to be a combination of both. In other words a line will end with $0D $0D $0A. I don't know if this is a result of some people editing in win32 Edit, some in linux vi or emacs or whatever you guys use, or if ir might be the lazarus editor doing it. At any rate, if freaks the win32 Edit out, showing little musical notes for the singleton $0D. I know, crappy editor... No big deal, just thought I'd mention it.

On to the CVS questions. What does CVS do to a source file that I have editted, and it detects there is a new version to be downloaded? It seems to be leaving it all in there, and commenting out what I have changed, but it's hard to tell, as the blocks are big, I have the editor problem mentioned above, and I can't get the lazarus IDE compiled to a point to use the syntax coloring. All I know is that after every update, it takes me a while to figure out just what is what. CVS docs are a bit hard to follow on this.

Jeff.