[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make cvs text agnostic?

From: Koti
Subject: Re: make cvs text agnostic?
Date: Wed, 28 Aug 2002 12:10:15 +0530
User-agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2


I would like share my thaughts on "Having repository in one OS and development in other OSes"

Actually I am windows developer, working on C++, VC++, etc those application I can not develop in UNIX platforlms and at same time there is no better source management tools on windows like CVS. So We have repositories on UNIOX of Linix platforms and check out sources to windows platforms and do work and commit to the repositories and I feel that It was very good.

At same time it is not very good to trust windows systems (Linux, Unix machines have more stable than windows machines.)
So it's better to have repositories on Unix or Linix servers irrespective of work env.


Paul Sander wrote:
--- Forwarded mail from address@hidden

Frederic Brehm wrote:
The CVS clients already do this. The problem comes when people use a 
file system cross mounted on several different kinds of OS, checkout on
one OS, and then edit and commit on another OS.

I wonder why people do this?  Anyway, it shouldn't matter, should it,
even what Jouni says is true (see below)

The practice is common in shops that have policies against committing
stuff that doesn't compile, and that require single sources that compile
on all of their supported platforms. The developers tend to check out
on their Unix boxes into a shared filesystem, debug and compile, then
switch to Windows to debug and compile there, and finally commit the code
from an arbitrary platform.

Autodetection of binary
There are enough times when autodetection gets the wrong answer that 
many people on this list will vigorously oppose having CVS doing this

Jouni Heikmniemi also mentioned that 8bit text would make it difficult. 
I still think that for the typical case (source code) the detection
would be quite reliable. And reversible, except if you use double
chars where one of the chars just happened to be the same as a \r or \n.

Unfortunately, there are many types of source code. For programs written
in, say, the C language, what you say is probably true. For message
catalogs whose purpose is to match numbers with text in some arbitrary
language, it's a bit harder.

Also, there are times going the other way, when a binary file is
erroneously recognized as text.

It is possible to build a mechanism that is accurate to any arbitrary
level, but certain vocal members of this group seem to think that if
it can't be 100% reliable out of the box then it isn't worth implementing.

--- End of forwarded message from address@hidden

Info-cvs mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]