On Friday, April 7, Pavel Roskin wrote:
> >>> the UNIX version barfs because the DOS version leaves ^M cookies at
> >>> the end of each line in CVS/Entries, CVS/Repository, CVS/Root
>
> I think that developers should not be encouraged to use "cvs commit" as
> way of transmitting files from one system to another. Many sites require
> that files are committed after testing on more than one platform.
Bonus, and that is entirely possible with CVS.
> My former employer required testing on 2 platforms for check-ins on the
> development branch and 6 (!!!) platforms for check-ins on the stable
> branch. This could be acomplished with "views" in ClearCase, but CVS would
> be of little help here.
Why, this is a matter for branches, diffs, multiple "sandboxes", and some
tags (for the bigger projects). It really is quite simple. And to you
people that say "my sandbox is 100+MB, it's not practical, etc", I say
"have you looked at the price of disk lately!?!"
> Let's leave it up to the build system to deal with shared working
> directories. Autoconf-enabled projects, for instance, can be built for
> many platforms from the same source directory. The question whether the
> working directory should be shared is out of scope of CVS.
This is one way of doing it. Much prefered way at times.
> I see nothing bad if CVS did its best to recognize all types of line
> endings.
Sure, if you wish to include that sort of code for CVS/* files, feel free.
However, and here is the crux. If you say "this is a bug, because the DOS
(substitute whatever OS you want here) version can't read and understand
the CVS/* files written by a UNIX (or whatever) version of cvs", then I tell
you, THAT IS NOT SUPPORTED. I DOUBT IT EVER WAS. In some sense, I'm glad
it does not work, it staves off people that are using things in a way it was
not designed. Saves me from having to rant and rave when the CVS/* formats
change in the future...
--Toby.
