This is the mail archive of the
mailing list for the Cygwin project.
Re: CVS Problems: Updated: gdbm-1.8.0-4
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: "Schaible, Jörg" <Joerg dot Schaible at gft dot com>
- Cc: cygwin-list <cygwin at sources dot redhat dot com>
- Date: Thu, 28 Feb 2002 12:18:35 -0500
- Subject: Re: CVS Problems: Updated: gdbm-1.8.0-4
- References: <1264BCF4F426D611B0B00050DA782A50110E30@mail.gft.com>
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
> 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.
> for Your comment seems to indicate some
> malfunction you're able to reproduce.
> I would not like to detect anything
> major problems managing my sources if I can avoid it.
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."
Somebody has mentioned that because of the WinCVS port, cvs already has
some code in it to manually do LF/CR->LF (and reverse) conversions...I
haven't looked yet. Perhaps all that's missing is for that code to get
"turned on" in the cygwin port. However, that still leaves the
sociological issues w.r.t. the already extant local repositories out
Anyway, I have over 300 messages relating to cvs sitting in a folder,
and I've got to got thru all of them, fix the problems reported (most
seem to be either this LF/CR thing, "I want to host a repo on a
textmount" or "I want to run cygwin-cvs in :pserver: daemon mode"...)
I think what I may do is merely port my existing cygwin-cvs stuff from
cvs-1.11.0 to cvs-1.11.1p1, with NO further changes. Release that as a
test release, and then solicit help fixing (a) and (b)...
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html