I don't currently host any cvs repository on a cygwin port of cvs, and
nevertheless, in the Linux-based repository, I have history files ( ,v
files) with CR/LF rather than just LF.
This is as it should be: those files are meant to be used by silly Win32
applications that expect CR/LF as end-of-record, and that's what they get
because I check out files without end-of-record conversion. Silly *nix
applications will, of course, see an CR at the end of each line; so what?
Please don't make the assumption that -kkv implies that CR cannot be the
last character on a line.
Kind regards
Peter Ring
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: 28. februar 2002 18:19
To: Schaible, Jörg
Cc: cygwin-list
Subject: Re: CVS Problems: Updated: gdbm-1.8.0-4
Schaible, Jörg wrote:
Hi Charles,
Note that merely updating cyggdbm to this new version will NOT
magically enable CVS to host repositories on text mounts; nor will
it magically fix CVS's existing problems with CR/LF. This gdbm
update may fix the gdbm database files within the CVSROOT repository,
but CVS itself is still not text/binary clean. Workin' on it...
can you give me a hint, where CVS with a repository on a binary mount
Correct, with repository on *binary* mounts cvs will work fine -- with
one caveat.
will
have CR/LF problems? I am using it since more than a year and I had never
detected any problems independently wether I check out to bin or text
mounted directories (on NTFS).
Correct, checkouts to bin or text -- from a binmount repository -- work
fine -- with one caveat.
I did not have problems also working with
repositories of the the net.
True.
for Your comment seems to indicate some
malfunction you're able to reproduce.
Yes.
I would not like to detect anything
major problems managing my sources if I can avoid it.
Understandable.
-
Here's the deal:
(a) currently, you can't host repositories on text mounts.
(b) the caveat for binmount-hosted repositories: the CVS spec says that
all 'normal' files in the repository should be stored *without* ^M (that
is, in what we in the cygwin world call bin mode or sometimes unix
mode -- but to avoid confusion, when refering to an actual FILE, I will
call it 'LF' mode (I will call dos or text files by this name:
LF/CR mode). When referring to a mount point and the cygwin default
behavior with respect to files written under that mount point, I will
call THAT bin mode or text mode, respectively.
Well, the current cygwin port of CVS seems to store all 'normal' files
in the repository in LF/CR mode. On checkout (from a local repository)
all 'normal' files are created in LF/CR mode. This is *regardless* of
whether the local working directory is on a binmount or textmount. (Of
course, the repository is on a binmount; see (a) above).
If a given file is checked in or tagged with cvs's '-kb' flag, then it
is stored without LF-LF/CR translation (and without LF/CR-LF
translation) -- but there are SERIOUS drawbacks to marking ordinary text
files as '-kb': like, you can't do 'cvs diff'. Multiple revisions are
stored _in toto_ in the repository. No keyword translation is done
($Id$, etc). Bad.
Strangely, none of these problems seem to occur when using a remote
(unix-based) :pserver: repository. Therefore, I believe the write data
file into repository file 'foo/bar,v' code is explicitly, and
erroneously, setting the fopen mode to wt/rt. Writes (and reads)
to/from files in the local repository are obviously done correctly --
without any explicit 't' or 'b' modifiers (because we know that local
dirs can be on textmounts or binmounts, and stuff 'just works').
What *should* happen is that repository writes need to manually
translate LF/CR into LF, and write with wb. (!!--!!)
--
Now, (a) is probably pretty easy to fix. The sentence marked (!!--!!)
should take care of that. However, (b) is a bigger problem -- because
of the existing infrastructure that many people already have. I don't
want to break the 2000 personal/local repositories out there that
already have a bunch of LF/CR-ized ,v files.
So, I'm somewhat at a loss right now as to the right thing to do.
Perhaps if all repository reads were also done by reading with rb and
then manually translating LF/CR into LF (this insures that
previously created repositories with the erroneous LF/CR endings are
handled gracefully) But then diffs against local working dirs on
binmounts -- where the checked-out copies already have
LF/CR-terminations will break...
Please run dos2unix on all text files in your working dir, IF your
working dir is on a binmount...bleah
For every working dir that is a checkout from a locally-hosted
repository, please commit all changes back to that repository before
upgrading CVS. Then, do a 'cvs release' on all working dirs. Remove
them. Upgrade CVS. Then check them back out using the new cvs.exe
