* [avail for test] cvs-1.11.5-1
@ 2003-04-25 10:42 Charles Wilson
2003-04-25 15:21 ` Max Bowsher
2003-05-21 9:03 ` Charles Wilson
0 siblings, 2 replies; 14+ messages in thread
From: Charles Wilson @ 2003-04-25 10:42 UTC (permalink / raw)
To: cygwin
USE AT YOUR OWN RISK.
But I would appreciate testing and feedback. This is an update to
version 1.11.5 from 1.11.0; there have been lots of changes under the
hood. cvs-1.11.5 adds the rlog command, as well as a number of
bugfixes. AFAIK, the server mode is still broken.
This version actually performs better on the self-tests than the old
cvs-1.11.0 version did, so that's good. I have not verified the
interaction of binary/text mounted repository directories with
binary/text mounted working dirs. (However, since text mounts were
basically broken in 1.11.0, any improvement in that area is gravy.)
binary-mounted text-mounted
repository dir repository dir
binary-mounted works ? (probably NOT work)
working dir
text-mounted ? ? (probably NOT work)
working dir
If this works as-well-as the old cvs-1.11.0 release, then I'll upload it
to sources -- even if it doesn't fix every old problem in 1.11.0.
To try it out -- NOT ON YOUR PRODUCTION MACHINE -- point setup at
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
--Chuck
----------------------------------------------------------------------
Table of contents:
Notes
Brief Summary of Test Failures
Gory Test Results
Of 123 local: tests and 123 remote: tests,
(each with many subtests), only the following
failures were observered:
local: modules remote: modules
local: modules6 remote: modules6
local: binfiles3 remote: binfiles3
local: errmsg1 remote: errmsg1
remote: devcom3
remote: crerepos
For Extremely Gory Test Results, see the files
cvs-1.11.5-1.check.localpass
cvs-1.11.5-1.check.localfail
cvs-1.11.5-1.check.remotepass
cvs-1.11.5-1.check.remotefail
which are in the 'release/cvs/' directory at the URL above.
--------------------------------------------
NOTES
--------------------------------------------
NOTES:
(0) All tests run on W2k, NTFS, cygwin=ntsec, binary mounts
for EVERYTHING, including the build dir, src dir, and
/tmp.
(1) I have made no attempt to fix or find any text/binary issues
in the cygwin port of cvs. It's entirely possible that any
extant issues have already been fixed in the official codebase.
It's also possible that bugs still lurk.
(2) The old cvs-1.11.0-1 cygwin release failed these tests
(only :local: access was tested):
join-readonly-conflict (subtest 1)
modules (subtest 148) failed with a coredump
errmsg1 (subtest 168)
binfiles3 (subtest 11)
rcs2 (subtest 7)
rcs3 (subtest 5)
So, the 1.11.5-1 actually performs better than 1.11.0-1; it
no longer fails the rcs2, rcs3, and join-readonly-conflict tests.
Of the four :local: failures, three are no change from the
earlier release. The only "new" failure is modules6 -- but
that test didn't exist in 1.11.0, so it isn't a regression, per se.
===> no regressions from cvs-1.11.0-1 <===
Further, we now can test pseudo-remote access using the :fork:
protocol, which mimics all of the remote access code by
forking a new copy of cvs.exe as a "local server". In that
case, the only test differences are:
:fork: fails devcom3
:fork: fails crerepos -- but that's expected
(3) coredumping is bad.
(4) Special 'targets' in the build script. After doing
cvs-1.11.5-1.sh conf, and build, you can also do:
cvs-1.11.5-1.sh check-local-pass
cvs-1.11.5-1.sh check-local-fail
cvs-1.11.5-1.sh check-remote-pass
cvs-1.11.5-1.sh check-remote-fail
check-local-pass runs all 119 local tests that I got successful
results for. Ditto check-remote-pass (117 passing tests).
However, check-local-fail and check-remote-fail run only the
few tests that failed in my testing.
(5) There may be a resource leak somewhere -- while the check-local-pass
tests run fine, I often got a "No space left on device" error
while running the check-remote-pass tests (even though I had PLENTY
of free disk space). These spurious failures would persist -- until
I rebooted the machine. At that point, I could continue the tests
from the point of failure, for another 30-40 tests.
This did NOT happen in :local: mode; only :fork: mode. It's
possible the :fork: code isn't closing file descriptors or
something...
However, I do not expect that these sorts of errors will crop up in
everyday usage.
--------------------------------------------
BRIEF SUMMARY OF TEST FAILURES
--------------------------------------------
FAILED TESTS:
local: modules (subtest modules-148a0)
causes a coredump...
local: modules6 (subtest modules6-1)
local: binfiles3 (subtest binfiles3-11)
expected. 'admin -o' is disabled on windows/cygwin
local: errmsg1 (subtest 168)
remote: modules (subtest modules-148a1)
again, causes a coredump
remote: modules6 (subtest modules6-1)
remote: binfiles3 (subtest binfiles3-11)
again, expected. 'admin -o' is disabled on windows/cygwin
remote: errmsg1 (subtest 168)
remote: devcom3 (subtest devcom3-9ar)
remote: crerepos
ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
when testing in remote mode, crerepos uses :ext: instead of
:fork:. However, even though I had rshd running -- it was
running as SYSTEM -- which means password entry is required.
This test expects passwordless rsh.
--------------------------------------------
GORY TEST DETAILS
--------------------------------------------
LOCAL TESTS
FAILED 4
modules
modules6
binfiles3
errmsg1
PASSED 119
version basica basicb basicc basic1
deep basic2 files spacefiles commit-readonly
commit-add-missing rdiff diff death death2
rm-update-message rmadd rmadd2 dirs dirs2
branches branches2 tagc tagf rcslib
multibranch import importb importc update-p
import-after-initial join join2 join3 join-readonly-conflict
join-admin join-admin-2 new newb conflicts
conflicts2 conflicts3 clean modules2 modules3
modules4 modules5 mkmodules-temp-file-removal cvsadm emptydir
abspath toplevel toplevel2 checkout_repository mflag
editor errmsg2 adderrmsg devcom devcom2
devcom3 watch4 watch5 unedit-without-baserev ignore
ignore-on-branch binfiles binfiles2 mcopy binwrap
binwrap2 binwrap3 mwrap info taginfo
config serverpatch log log2 logopt
ann ann-id crerepos rcs rcs2
rcs3 lockfiles backuprecover history big
modes modes2 modes3 stamps sticky
keyword keyword2 keywordlog head tagdate
multibranch2 tag8k admin reserved diffmerge1
diffmerge2 release multiroot multiroot2 multiroot3
multiroot4 rmroot reposmv pserver server
server2 client fork commit-d
REMOTE TESTS: (uses :fork:, not :ext: or :pserver:)
FAILED 5
modules
modules6
binfiles3
errmsg1
devcom3
crerepos
PASSED 117
version basica basicb basicc basic1
deep basic2 files spacefiles commit-readonly
commit-add-missing rdiff diff death death2
rm-update-message rmadd rmadd2 dirs dirs2
branches branches2 tagc tagf rcslib
multibranch import importb importc update-p
import-after-initial join join2 join3 join-readonly-conflict
join-admin join-admin-2 new newb conflicts
conflicts2 conflicts3 clean modules2 modules3
modules4 modules5 mkmodules-temp-file-removal cvsadm emptydir
abspath toplevel toplevel2 checkout_repository mflag
editor errmsg2 adderrmsg devcom devcom2
watch4 watch5 unedit-without-baserev ignore ignore-on-branch
binfiles binfiles2 mcopy binwrap binwrap2
binwrap3 mwrap info taginfo config
serverpatch log log2 logopt ann
ann-id rcs rcs2 rcs3 lockfiles
backuprecover history big modes modes2
modes3 stamps sticky keyword keyword2
keywordlog head tagdate multibranch2 tag8k
admin reserved diffmerge1 diffmerge2 release
multiroot multiroot2 multiroot3 multiroot4 rmroot
reposmv pserver server server2 client
fork commit-d
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-25 10:42 [avail for test] cvs-1.11.5-1 Charles Wilson
@ 2003-04-25 15:21 ` Max Bowsher
2003-04-26 2:02 ` Charles Wilson
2003-04-26 21:46 ` Charles Wilson
2003-05-21 9:03 ` Charles Wilson
1 sibling, 2 replies; 14+ messages in thread
From: Max Bowsher @ 2003-04-25 15:21 UTC (permalink / raw)
To: Charles Wilson, cygwin
Charles Wilson wrote:
> USE AT YOUR OWN RISK.
>
> But I would appreciate testing and feedback. This is an update to
> version 1.11.5 from 1.11.0; there have been lots of changes under the
> hood. cvs-1.11.5 adds the rlog command, as well as a number of
> bugfixes. AFAIK, the server mode is still broken.
....
> remote: crerepos
> ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
> when testing in remote mode, crerepos uses :ext: instead of
> :fork:. However, even though I had rshd running -- it was
> running as SYSTEM -- which means password entry is required.
> This test expects passwordless rsh.
This works if you set up passwordless ssh back to your own machine and set
the envvars to point cvs at ssh rather than rsh.
Also, a couple of packaging points:
- I don't think re-autotooling was necessary.
- Your port notes in the README don't mention the change from gdbm to
flat-file.
So, this is basically stock 1.11.5, which I have been using for my
day-to-day cvs-ing for months.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-25 15:21 ` Max Bowsher
@ 2003-04-26 2:02 ` Charles Wilson
2003-04-26 2:25 ` Max Bowsher
2003-04-26 21:46 ` Charles Wilson
1 sibling, 1 reply; 14+ messages in thread
From: Charles Wilson @ 2003-04-26 2:02 UTC (permalink / raw)
To: Max Bowsher; +Cc: cygwin
Max Bowsher wrote:
> Charles Wilson wrote:
>
>>USE AT YOUR OWN RISK.
>>
>>But I would appreciate testing and feedback. This is an update to
>>version 1.11.5 from 1.11.0; there have been lots of changes under the
>>hood. cvs-1.11.5 adds the rlog command, as well as a number of
>>bugfixes. AFAIK, the server mode is still broken.
>
> ....
>
>
>>remote: crerepos
>> ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
>> when testing in remote mode, crerepos uses :ext: instead of
>> :fork:. However, even though I had rshd running -- it was
>> running as SYSTEM -- which means password entry is required.
>> This test expects passwordless rsh.
>
>
> This works if you set up passwordless ssh back to your own machine and set
> the envvars to point cvs at ssh rather than rsh.
Right -- but "passwordless" ssh means that the sshd must be running as
the user you want to log in as. I was running sshd under SYSTEM...so no
luck there.
But you note that this is NOT a cvs server -- it's really logging in to
the "remote" machine via ssh and running cvs "on the 'server'". cvs
itself is not listening for incoming connections.
> Also, a couple of packaging points:
>
> - I don't think re-autotooling was necessary.
>
> - Your port notes in the README don't mention the change from gdbm to
> flat-file.
I did not change from gdbm to flat file -- at least not on purpose. In
fact, I added a lot of configury code to enable linkage to gdbm. So
your comment that "re autotooling was [not] necessary" is nonsense -- I
modified configure.in and at least one Makefile.am -- of COURSE I had to
reautotool.
> So, this is basically stock 1.11.5, which I have been using for my
> day-to-day cvs-ing for months.
No, after removing the autotool detritus, the patch is still 27k, and
touches the following files:
cvs-1.11.5/CYGWIN-PATCHES/cvs.README
cvs-1.11.5/CYGWIN-PATCHES/postinstall.sh
cvs-1.11.5/CYGWIN-PATCHES/setup.hint
cvs-1.11.5/configure.in
cvs-1.11.5/lib/system.h
cvs-1.11.5/src/Makefile.am
cvs-1.11.5/src/cvs.h
cvs-1.11.5/src/gdbm_wrap.c
cvs-1.11.5/src/gdbm_wrap.h
cvs-1.11.5/src/mkmodules.c
cvs-1.11.5/src/modules.c
cvs-1.11.5/src/myndbm.h
cvs-1.11.5/src/rcs.c
cvs-1.11.5/src/sanity.sh
cvs-1.11.5/src/tag.c
cvs-1.11.5/windows-NT/README
It's definitely NOT stock, unless I screwed up.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 2:02 ` Charles Wilson
@ 2003-04-26 2:25 ` Max Bowsher
2003-04-26 9:25 ` Charles Wilson
0 siblings, 1 reply; 14+ messages in thread
From: Max Bowsher @ 2003-04-26 2:25 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
Charles Wilson wrote:
> Max Bowsher wrote:
>
>> Charles Wilson wrote:
>>
>>> USE AT YOUR OWN RISK.
>>>
>>> But I would appreciate testing and feedback. This is an update to
>>> version 1.11.5 from 1.11.0; there have been lots of changes under the
>>> hood. cvs-1.11.5 adds the rlog command, as well as a number of
>>> bugfixes. AFAIK, the server mode is still broken.
>>
>> ....
>>
>>
>>> remote: crerepos
>>> ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
>>> when testing in remote mode, crerepos uses :ext: instead of
>>> :fork:. However, even though I had rshd running -- it was
>>> running as SYSTEM -- which means password entry is required.
>>> This test expects passwordless rsh.
>>
>>
>> This works if you set up passwordless ssh back to your own machine and
set
>> the envvars to point cvs at ssh rather than rsh.
>
> Right -- but "passwordless" ssh means that the sshd must be running as
> the user you want to log in as. I was running sshd under SYSTEM...so no
> luck there.
Passphraseless pubkey auth works just fine with sshd as SYSTEM.
> But you note that this is NOT a cvs server -- it's really logging in to
> the "remote" machine via ssh and running cvs "on the 'server'". cvs
> itself is not listening for incoming connections.
Oops... now I see how my snippage could have caused confusion. I just left
in the stuff at the top for basic context. I just wanted to say that the
remote crerepos test will pass if it has the right support. I wasn't
thinking about server mode.
----
Sorry about all this below:
>> Also, a couple of packaging points:
>>
>> - I don't think re-autotooling was necessary.
>>
>> - Your port notes in the README don't mention the change from gdbm to
>> flat-file.
>
> I did not change from gdbm to flat file -- at least not on purpose. In
> fact, I added a lot of configury code to enable linkage to gdbm. So
> your comment that "re autotooling was [not] necessary" is nonsense -- I
> modified configure.in and at least one Makefile.am -- of COURSE I had to
> reautotool.
>
>> So, this is basically stock 1.11.5, which I have been using for my
>> day-to-day cvs-ing for months.
>
> No, after removing the autotool detritus, the patch is still 27k, and
> touches the following files:
...
> It's definitely NOT stock, unless I screwed up.
It seems 'lsdiff' screwed up:
$ lsdiff cvs-1.11.5-1.patch
cvs-1.11.5/CYGWIN-PATCHES/cvs.README
cvs-1.11.5/CYGWIN-PATCHES/postinstall.sh
cvs-1.11.5/CYGWIN-PATCHES/setup.hint
cvs-1.11.5/Makefile.in
cvs-1.11.5/aclocal.m4
cvs-1.11.5/config.h.in
cvs-1.11.5/configure
$
Whereas fgrep '+++' shows the truth.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 2:25 ` Max Bowsher
@ 2003-04-26 9:25 ` Charles Wilson
0 siblings, 0 replies; 14+ messages in thread
From: Charles Wilson @ 2003-04-26 9:25 UTC (permalink / raw)
To: cygwin
Max Bowsher wrote:
>>But you note that this is NOT a cvs server -- it's really logging in to
>>the "remote" machine via ssh and running cvs "on the 'server'". cvs
>>itself is not listening for incoming connections.
>
>
> Oops... now I see how my snippage could have caused confusion. I just left
> in the stuff at the top for basic context. I just wanted to say that the
> remote crerepos test will pass if it has the right support. I wasn't
> thinking about server mode.
Yes, I thought you were deliberately making a connection between those
two paragraphs.
> Sorry about all this below:
'salright.
> It seems 'lsdiff' screwed up:
> Whereas fgrep '+++' shows the truth.
That's odd. Hmph.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-25 15:21 ` Max Bowsher
2003-04-26 2:02 ` Charles Wilson
@ 2003-04-26 21:46 ` Charles Wilson
2003-04-26 22:01 ` Max Bowsher
1 sibling, 1 reply; 14+ messages in thread
From: Charles Wilson @ 2003-04-26 21:46 UTC (permalink / raw)
To: cygwin
Max Bowsher wrote:
> So, this is basically stock 1.11.5, which I have been using for my
> day-to-day cvs-ing for months.
Since none of my changes impact the process of writing files to disk
(okay, with MAYBE the limited exception of ${CVSROOT}/CVSROOT/modules.db
and valtags.db), the bits-to-disk and disk-to-bits stuff is stock
1.11.5. So Max, what has your experience been with:
binary-mounted text-mounted
repository dir repository dir
binary-mounted works ? (probably NOT work)
working dir
text-mounted ? ? (probably NOT work)
working dir
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 21:46 ` Charles Wilson
@ 2003-04-26 22:01 ` Max Bowsher
2003-04-26 23:18 ` Charles Wilson
0 siblings, 1 reply; 14+ messages in thread
From: Max Bowsher @ 2003-04-26 22:01 UTC (permalink / raw)
To: Charles Wilson, cygwin
Charles Wilson wrote:
> Max Bowsher wrote:
>
>> So, this is basically stock 1.11.5, which I have been using for my
>> day-to-day cvs-ing for months.
>
> Since none of my changes impact the process of writing files to disk
> (okay, with MAYBE the limited exception of ${CVSROOT}/CVSROOT/modules.db
> and valtags.db), the bits-to-disk and disk-to-bits stuff is stock
> 1.11.5. So Max, what has your experience been with:
>
> binary-mounted text-mounted
> repository dir repository dir
>
> binary-mounted works ? (probably NOT work)
> working dir
>
> text-mounted ? ? (probably NOT work)
> working dir
Only tested binary/binary, I'm afraid.
I've never liked the idea of using 2 characters where 1 will do. I even use
Unix line endings in non-Cygwin text files.
One possible idea: Link it with binmode.o until someone contributes a patch
to apply correct binary/text/default opens in the source.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 22:01 ` Max Bowsher
@ 2003-04-26 23:18 ` Charles Wilson
2003-04-27 0:01 ` Max Bowsher
2003-04-27 0:53 ` Igor Pechtchanski
0 siblings, 2 replies; 14+ messages in thread
From: Charles Wilson @ 2003-04-26 23:18 UTC (permalink / raw)
To: cygwin
Max Bowsher wrote:
>
> Only tested binary/binary, I'm afraid.
>
> I've never liked the idea of using 2 characters where 1 will do. I even use
> Unix line endings in non-Cygwin text files.
>
> One possible idea: Link it with binmode.o until someone contributes a patch
> to apply correct binary/text/default opens in the source.
Well, the problem is that's not how cvs is supposed to work. As I
understand it, files in the repository should ALWAYS be stored with unix
line-endings (the term "binary" is slightly misleading in this context,
as -kb "store in binary form" means to cvs "don't replace $foo$ tokens
like $Id$ and $Revision$").
And files in the local working directory should follow "the system
convention" -- which I take to mean "use the mount mode" -- but only
when the files contain text. Fortunately, cvs assumes that all files
contain text unless explicitly informed that they are binary data, via
the -kb flag. Thus,
repository working dir
access access
---------------------------------------------
read: unix use mount mode unless -kb
write: unix use mount mode unless -kb
(fortunately, the "should I interpret/replace $foo$" stuff is handled in
a separate codepath from the "should I use O_BINARY to fopen this file")
Now IF existing repositories do NOT follow this convention (e.g.
somebody has \r\n in text files in their repository) then upgrading to a
cvs that DOES follow the convention will lead to all manner of FAQs
("cvs diff says every line has changed! cvs sucks!)
Anyway, there's lots of places to screw up, so testing is a must -- and
I haven't even attempted to suss out the code to see if it is behaving
-- on cygwin -- as advertised in the table above.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 23:18 ` Charles Wilson
@ 2003-04-27 0:01 ` Max Bowsher
2003-04-27 0:53 ` Igor Pechtchanski
1 sibling, 0 replies; 14+ messages in thread
From: Max Bowsher @ 2003-04-27 0:01 UTC (permalink / raw)
To: Charles Wilson, cygwin
Charles Wilson wrote:
> Max Bowsher wrote:
>> Only tested binary/binary, I'm afraid.
>>
>> I've never liked the idea of using 2 characters where 1 will do. I even
use
>> Unix line endings in non-Cygwin text files.
>>
>> One possible idea: Link it with binmode.o until someone contributes a
patch
>> to apply correct binary/text/default opens in the source.
>
> Well, the problem is that's not how cvs is supposed to work. As I
> understand it, files in the repository should ALWAYS be stored with unix
> line-endings (the term "binary" is slightly misleading in this context,
> as -kb "store in binary form" means to cvs "don't replace $foo$ tokens
> like $Id$ and $Revision$").
Um, no -ko means that. -kb DOES mean store in binary form.
> And files in the local working directory should follow "the system
> convention" -- which I take to mean "use the mount mode" -- but only
> when the files contain text. Fortunately, cvs assumes that all files
> contain text unless explicitly informed that they are binary data, via
> the -kb flag. Thus,
>
> repository working dir
> access access
> ---------------------------------------------
> read: unix use mount mode unless -kb
> write: unix use mount mode unless -kb
Well, yeah, my suggestion was to use binmode.o *until* someone actually does
a patch to do the above.
> (fortunately, the "should I interpret/replace $foo$" stuff is handled in
> a separate codepath from the "should I use O_BINARY to fopen this file")
>
> Now IF existing repositories do NOT follow this convention (e.g.
> somebody has \r\n in text files in their repository) then upgrading to a
> cvs that DOES follow the convention will lead to all manner of FAQs
> ("cvs diff says every line has changed! cvs sucks!)
Lets hope that no one is trying to use -kb in such a situation.
But yes, status quo is probably better, since there don't seem to be any
complaints about the current behaviour.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-26 23:18 ` Charles Wilson
2003-04-27 0:01 ` Max Bowsher
@ 2003-04-27 0:53 ` Igor Pechtchanski
1 sibling, 0 replies; 14+ messages in thread
From: Igor Pechtchanski @ 2003-04-27 0:53 UTC (permalink / raw)
To: Charles Wilson; +Cc: cygwin
On Sat, 26 Apr 2003, Charles Wilson wrote:
> Max Bowsher wrote:
>
> > Only tested binary/binary, I'm afraid.
> >
> > I've never liked the idea of using 2 characters where 1 will do. I even use
> > Unix line endings in non-Cygwin text files.
> >
> > One possible idea: Link it with binmode.o until someone contributes a patch
> > to apply correct binary/text/default opens in the source.
>
> Well, the problem is that's not how cvs is supposed to work. As I
> understand it, files in the repository should ALWAYS be stored with unix
> line-endings (the term "binary" is slightly misleading in this context,
> as -kb "store in binary form" means to cvs "don't replace $foo$ tokens
> like $Id$ and $Revision$").
>
> And files in the local working directory should follow "the system
> convention" -- which I take to mean "use the mount mode" -- but only
> when the files contain text. Fortunately, cvs assumes that all files
> contain text unless explicitly informed that they are binary data, via
> the -kb flag. Thus,
>
> repository working dir
> access access
> ---------------------------------------------
> read: unix use mount mode unless -kb
> write: unix use mount mode unless -kb
>
> (fortunately, the "should I interpret/replace $foo$" stuff is handled in
> a separate codepath from the "should I use O_BINARY to fopen this file")
>
> Now IF existing repositories do NOT follow this convention (e.g.
> somebody has \r\n in text files in their repository) then upgrading to a
> cvs that DOES follow the convention will lead to all manner of FAQs
> ("cvs diff says every line has changed! cvs sucks!)
>
> Anyway, there's lots of places to screw up, so testing is a must -- and
> I haven't even attempted to suss out the code to see if it is behaving
> -- on cygwin -- as advertised in the table above.
> --Chuck
Chuck,
Note that the repository files themselves (i.e., "*,v") should have LF
line endings. The data stored in those files might well have CRLF in
it... Sorry if I'm restating the obvious.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu
ZZZzz /,`.-'`' -. ;-;;,_ igor@watson.ibm.com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
Knowledge is an unending adventure at the edge of uncertainty.
-- Leto II
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-04-25 10:42 [avail for test] cvs-1.11.5-1 Charles Wilson
2003-04-25 15:21 ` Max Bowsher
@ 2003-05-21 9:03 ` Charles Wilson
2003-05-21 17:40 ` Rick Rankin
1 sibling, 1 reply; 14+ messages in thread
From: Charles Wilson @ 2003-05-21 9:03 UTC (permalink / raw)
To: cygwin
Okay, this has been in 'test' for a month now. Has anybody (besides me)
tested it? Anyone? Anyone?
Bueller?
Okaaayyy, one more week and then I'm promoting it to 'curr' -- so if
there's problems, ya'll better find 'em now and not later.
--Chuck
Charles Wilson wrote:
> USE AT YOUR OWN RISK.
>
> But I would appreciate testing and feedback. This is an update to
> version 1.11.5 from 1.11.0; there have been lots of changes under the
> hood. cvs-1.11.5 adds the rlog command, as well as a number of
> bugfixes. AFAIK, the server mode is still broken.
>
> This version actually performs better on the self-tests than the old
> cvs-1.11.0 version did, so that's good. I have not verified the
> interaction of binary/text mounted repository directories with
> binary/text mounted working dirs. (However, since text mounts were
> basically broken in 1.11.0, any improvement in that area is gravy.)
>
> binary-mounted text-mounted
> repository dir repository dir
>
> binary-mounted works ? (probably NOT work)
> working dir
>
> text-mounted ? ? (probably NOT work)
> working dir
>
>
> If this works as-well-as the old cvs-1.11.0 release, then I'll upload it
> to sources -- even if it doesn't fix every old problem in 1.11.0.
>
> To try it out -- NOT ON YOUR PRODUCTION MACHINE -- point setup at
> http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
>
> --Chuck
>
>
> ----------------------------------------------------------------------
> Table of contents:
> Notes
> Brief Summary of Test Failures
> Gory Test Results
>
> Of 123 local: tests and 123 remote: tests,
> (each with many subtests), only the following
> failures were observered:
>
> local: modules remote: modules
> local: modules6 remote: modules6
> local: binfiles3 remote: binfiles3
> local: errmsg1 remote: errmsg1
> remote: devcom3
> remote: crerepos
>
> For Extremely Gory Test Results, see the files
> cvs-1.11.5-1.check.localpass
> cvs-1.11.5-1.check.localfail
> cvs-1.11.5-1.check.remotepass
> cvs-1.11.5-1.check.remotefail
> which are in the 'release/cvs/' directory at the URL above.
>
> --------------------------------------------
> NOTES
> --------------------------------------------
>
> NOTES:
> (0) All tests run on W2k, NTFS, cygwin=ntsec, binary mounts
> for EVERYTHING, including the build dir, src dir, and
> /tmp.
>
> (1) I have made no attempt to fix or find any text/binary issues
> in the cygwin port of cvs. It's entirely possible that any
> extant issues have already been fixed in the official codebase.
> It's also possible that bugs still lurk.
>
> (2) The old cvs-1.11.0-1 cygwin release failed these tests
> (only :local: access was tested):
>
> join-readonly-conflict (subtest 1)
> modules (subtest 148) failed with a coredump
> errmsg1 (subtest 168)
> binfiles3 (subtest 11)
> rcs2 (subtest 7)
> rcs3 (subtest 5)
>
> So, the 1.11.5-1 actually performs better than 1.11.0-1; it
> no longer fails the rcs2, rcs3, and join-readonly-conflict tests.
> Of the four :local: failures, three are no change from the
> earlier release. The only "new" failure is modules6 -- but
> that test didn't exist in 1.11.0, so it isn't a regression, per se.
>
> ===> no regressions from cvs-1.11.0-1 <===
>
> Further, we now can test pseudo-remote access using the :fork:
> protocol, which mimics all of the remote access code by
> forking a new copy of cvs.exe as a "local server". In that
> case, the only test differences are:
> :fork: fails devcom3
> :fork: fails crerepos -- but that's expected
>
> (3) coredumping is bad.
>
> (4) Special 'targets' in the build script. After doing
> cvs-1.11.5-1.sh conf, and build, you can also do:
>
> cvs-1.11.5-1.sh check-local-pass
> cvs-1.11.5-1.sh check-local-fail
> cvs-1.11.5-1.sh check-remote-pass
> cvs-1.11.5-1.sh check-remote-fail
>
> check-local-pass runs all 119 local tests that I got successful
> results for. Ditto check-remote-pass (117 passing tests).
> However, check-local-fail and check-remote-fail run only the
> few tests that failed in my testing.
>
> (5) There may be a resource leak somewhere -- while the check-local-pass
> tests run fine, I often got a "No space left on device" error
> while running the check-remote-pass tests (even though I had PLENTY
> of free disk space). These spurious failures would persist -- until
> I rebooted the machine. At that point, I could continue the tests
> from the point of failure, for another 30-40 tests.
>
> This did NOT happen in :local: mode; only :fork: mode. It's
> possible the :fork: code isn't closing file descriptors or
> something...
>
> However, I do not expect that these sorts of errors will crop up in
> everyday usage.
>
> --------------------------------------------
> BRIEF SUMMARY OF TEST FAILURES
> --------------------------------------------
>
>
> FAILED TESTS:
>
> local: modules (subtest modules-148a0)
> causes a coredump...
>
> local: modules6 (subtest modules6-1)
>
> local: binfiles3 (subtest binfiles3-11)
> expected. 'admin -o' is disabled on windows/cygwin
>
> local: errmsg1 (subtest 168)
>
>
> remote: modules (subtest modules-148a1)
> again, causes a coredump
>
> remote: modules6 (subtest modules6-1)
>
> remote: binfiles3 (subtest binfiles3-11)
> again, expected. 'admin -o' is disabled on windows/cygwin
>
> remote: errmsg1 (subtest 168)
>
> remote: devcom3 (subtest devcom3-9ar)
>
> remote: crerepos
> ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
> when testing in remote mode, crerepos uses :ext: instead of
> :fork:. However, even though I had rshd running -- it was
> running as SYSTEM -- which means password entry is required.
> This test expects passwordless rsh.
>
> --------------------------------------------
> GORY TEST DETAILS
> --------------------------------------------
>
> LOCAL TESTS
>
> FAILED 4
> modules
> modules6
> binfiles3
> errmsg1
>
> PASSED 119
> version basica basicb basicc basic1
> deep basic2 files spacefiles commit-readonly
> commit-add-missing rdiff diff death death2
> rm-update-message rmadd rmadd2 dirs dirs2
> branches branches2 tagc tagf rcslib
> multibranch import importb importc update-p
> import-after-initial join join2 join3 join-readonly-conflict
> join-admin join-admin-2 new newb conflicts
> conflicts2 conflicts3 clean modules2 modules3
> modules4 modules5 mkmodules-temp-file-removal cvsadm emptydir
> abspath toplevel toplevel2 checkout_repository mflag
> editor errmsg2 adderrmsg devcom devcom2
> devcom3 watch4 watch5 unedit-without-baserev ignore
> ignore-on-branch binfiles binfiles2 mcopy binwrap
> binwrap2 binwrap3 mwrap info taginfo
> config serverpatch log log2 logopt
> ann ann-id crerepos rcs rcs2
> rcs3 lockfiles backuprecover history big
> modes modes2 modes3 stamps sticky
> keyword keyword2 keywordlog head tagdate
> multibranch2 tag8k admin reserved diffmerge1
> diffmerge2 release multiroot multiroot2 multiroot3
> multiroot4 rmroot reposmv pserver server
> server2 client fork commit-d
>
> REMOTE TESTS: (uses :fork:, not :ext: or :pserver:)
>
> FAILED 5
> modules
> modules6
> binfiles3
> errmsg1
> devcom3
> crerepos
>
> PASSED 117
> version basica basicb basicc basic1
> deep basic2 files spacefiles commit-readonly
> commit-add-missing rdiff diff death death2
> rm-update-message rmadd rmadd2 dirs dirs2
> branches branches2 tagc tagf rcslib
> multibranch import importb importc update-p
> import-after-initial join join2 join3 join-readonly-conflict
> join-admin join-admin-2 new newb conflicts
> conflicts2 conflicts3 clean modules2 modules3
> modules4 modules5 mkmodules-temp-file-removal cvsadm emptydir
> abspath toplevel toplevel2 checkout_repository mflag
> editor errmsg2 adderrmsg devcom devcom2
> watch4 watch5 unedit-without-baserev ignore ignore-on-branch
> binfiles binfiles2 mcopy binwrap binwrap2
> binwrap3 mwrap info taginfo config
> serverpatch log log2 logopt ann
> ann-id rcs rcs2 rcs3 lockfiles
> backuprecover history big modes modes2
> modes3 stamps sticky keyword keyword2
> keywordlog head tagdate multibranch2 tag8k
> admin reserved diffmerge1 diffmerge2 release
> multiroot multiroot2 multiroot3 multiroot4 rmroot
> reposmv pserver server server2 client
> fork commit-d
>
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-05-21 9:03 ` Charles Wilson
@ 2003-05-21 17:40 ` Rick Rankin
2003-05-22 4:12 ` Charles Wilson
0 siblings, 1 reply; 14+ messages in thread
From: Rick Rankin @ 2003-05-21 17:40 UTC (permalink / raw)
To: cygwin
--- Charles Wilson wrote:
> Okay, this has been in 'test' for a month now. Has anybody (besides me)
> tested it? Anyone? Anyone?
>
I've been using it fairly regularly. No problems here...
--Rick
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
2003-05-21 17:40 ` Rick Rankin
@ 2003-05-22 4:12 ` Charles Wilson
0 siblings, 0 replies; 14+ messages in thread
From: Charles Wilson @ 2003-05-22 4:12 UTC (permalink / raw)
To: cygwin
Rick Rankin wrote:
>>Okay, this has been in 'test' for a month now. Has anybody (besides me)
>>tested it? Anyone? Anyone?
>>
>
>
> I've been using it fairly regularly. No problems here...
Thanks for testing. I just realized that the 'test' phase I referred to
was not, in fact, an official test phase. It was "pre-test" because the
binaries were actually on my website, and NOT on the official cygwin
mirrors.
So, I've now put cvs-1.11.5-1 on the official mirror system, marked
'test' for the next week or so. I'll re-announce this availability on a
new thread.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [avail for test] cvs-1.11.5-1
@ 2003-04-25 13:40 Roland Schwingel
0 siblings, 0 replies; 14+ messages in thread
From: Roland Schwingel @ 2003-04-25 13:40 UTC (permalink / raw)
To: cygwin
Hi...
cygwin-owner@cygwin.com wrote on 25.04.2003 06:11:22:
> USE AT YOUR OWN RISK.
>
> But I would appreciate testing and feedback. This is an update to
> version 1.11.5 from 1.11.0; there have been lots of changes under the
> hood. cvs-1.11.5 adds the rlog command, as well as a number of
> bugfixes. AFAIK, the server mode is still broken.
>
> This version actually performs better on the self-tests than the old
> cvs-1.11.0 version did, so that's good. I have not verified the
> interaction of binary/text mounted repository directories with
> binary/text mounted working dirs. (However, since text mounts were
> basically broken in 1.11.0, any improvement in that area is gravy.)
2 or 3 months ago I already took cvs 1.11.5 and compiled it on my own.
(no modifications - just compiled)
I use it all day on cygwin and had NO problems at all.. Because of
speed, yes it is faster,
not much but noticeable - I put it on the fact that it is now compiled
with gcc3
(I did it with -O3), before (as far as I can tell it was gcc2).
Roland
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-05-22 3:26 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-25 10:42 [avail for test] cvs-1.11.5-1 Charles Wilson
2003-04-25 15:21 ` Max Bowsher
2003-04-26 2:02 ` Charles Wilson
2003-04-26 2:25 ` Max Bowsher
2003-04-26 9:25 ` Charles Wilson
2003-04-26 21:46 ` Charles Wilson
2003-04-26 22:01 ` Max Bowsher
2003-04-26 23:18 ` Charles Wilson
2003-04-27 0:01 ` Max Bowsher
2003-04-27 0:53 ` Igor Pechtchanski
2003-05-21 9:03 ` Charles Wilson
2003-05-21 17:40 ` Rick Rankin
2003-05-22 4:12 ` Charles Wilson
2003-04-25 13:40 Roland Schwingel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).