RE: CVS Problems: Updated: gdbm-1.8.0-4

RE: CVS Problems: Updated: gdbm-1.8.0-4

["Schaible, Jörg"]

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 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). 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.

Regards,
Jörg

internal for Corinna: Sorry, I did not recognize the 'wrong list' pressing
reply ...

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: CVS Problems: Updated: gdbm-1.8.0-4

[Charles Wilson]

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." 
Double bleah....

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 
there...

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)...

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: CVS Problems: Updated: gdbm-1.8.0-4

[Charles Wilson]

Charles Wilson wrote:


> 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" -- 

                              ^^^^^^^^^^
                           working directory

> without any explicit 't' or 'b' modifiers (because we know that local 
> dirs can be on textmounts or binmounts, and stuff 'just works').


--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: CVS Problems: Updated: gdbm-1.8.0-4

[Jason Tishler]

Chuck,

On Thu, Feb 28, 2002 at 12:18:35PM -0500, Charles Wilson wrote:
> 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).

Is the above really true?  I have empirical evidence to the contrary.
I just tried a local repository cvs init, import, and checkout with all
mounts in bin mode.  All files in the repository and working directories
end up in LF mode.

Jason

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: CVS Problems: Updated: gdbm-1.8.0-4

[Charles Wilson]

Jason Tishler wrote:

> Chuck,
> 
> On Thu, Feb 28, 2002 at 12:18:35PM -0500, Charles Wilson wrote:
> 
>>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).
>>
> 
> Is the above really true?  I have empirical evidence to the contrary.
> I just tried a local repository cvs init, import, and checkout with all
> mounts in bin mode.  All files in the repository and working directories
> end up in LF mode.


?????

I had precisely the OPPOSITE experience -- with all mounts in bin mode. 
  I started with files with LF endings.  I imported them -- and the new 
repository files had LF/CR.  I then checked them out (to a separate 
location) -- and the new working dir had LF/CR.

Damn.  I'm gonna have to look at this harder...

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: CVS Problems: Updated: gdbm-1.8.0-4

["Schaible, Jörg"]

Hi Charles and Jason,

>On Thu, Feb 28, 2002 at 12:18:35PM -0500, Charles Wilson wrote:
>> 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).
>
>Is the above really true?  I have empirical evidence to the contrary.
>I just tried a local repository cvs init, import, and checkout with all
>mounts in bin mode.  All files in the repository and working 
>directories
>end up in LF mode.

this is exacly my experience, too. Every file in my repository on the bin
mount has lf line endings ...

Regards,
Jörg 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: CVS Problems: Updated: gdbm-1.8.0-4

[Peter Ring]

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:cwilson@ece.gatech.edu]
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." 
Double bleah....

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 
there...

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)...

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/