public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: cvs-1.11.2 test release
@ 2002-06-17 12:55 Phil Dempster
  2002-06-17 13:15 ` Charles Wilson
  0 siblings, 1 reply; 8+ messages in thread
From: Phil Dempster @ 2002-06-17 12:55 UTC (permalink / raw)
  To: cygwin

I am wholeheartedly in favour of the cvsnt port approach.

Whilst I have managed to get cvs :pserver: running from inetd under Cygwin,
its not been without a reasonable amount of pain and a few annoying residual
quirks.  I would also like to see :ntserver: support.

Personally, I prefer the inetd approach to a standalone daemon - seems to me
there's too many services running already under Windows.  The closer the
configuration is to Linux the better (since I work with both).

/phil


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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* cvs-1.11.2 test release
@ 2002-05-19 22:14 Charles Wilson
  2002-05-20 22:37 ` Charles Wilson
  0 siblings, 1 reply; 8+ messages in thread
From: Charles Wilson @ 2002-05-19 22:14 UTC (permalink / raw)
  To: cygwin

I've made a test release of cvs-1.11.2-1 available on my website.
This version isn't even ready for 'normal' testing use; do NOT use
it for your day-to-day cvs'ing.  ONLY use it if you actively want
to help squash bugs.  (however, it does pass more of the selftest suite 
than the existing 1.11.0-1 release -- but I give NO WARRANTY, EXPRESS OR 
IMPLIED, that 1.11.2-1 will work in day-to-day use or not).

Using setup, you need to add this URL to your mirror list:

   http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/

Then, you must explicitly click thru the version numbers for the
cvs package until 1.11.2-1 shows up.

The purpose of this test release is NOT to fix existing bugs, but instead to
   1) update to current sources (1.11.2)
   2) migrate to "script-based" building

That way, other folks will have an easier time building cvs ( and thus, 
helping and providing patches.)  I'm reminded of the post a few days ago 
where somebody "fixed" cvs's build -- by deliberately removing MY_NDBM 
which serves only to BREAK cvs on FAT...sigh).  Arguably, that was my 
fault -- the earlier -src package was not trivial to build, and required 
manual intervention.

Also, by using the most current official version of cvs, we will be 
working with the best available code instead of two-year-out-of-date code.

But, I have NOT tried to actually FIX any extant issues.  That's up to 
you guys.  Patches, patches, patches...

rambling side note: we don't want to link against automode.o -- read 
EVERYTHING in text mode (e.g. strip out \r's), and write EVERYTHING in 
binary mode (e.g. don't put the \r's back).  Effectively, this will 
eventually dos2unix convert all the accessed files. We don't want to do 
that because it wouldn't be appropriate for all files -- what of .png's 
checked in with -kb?  You never want to open those textmode.

However, it WOULD be good to use 'automode' on .cvsrc, .cvspass, and the 
ROOT, ENTRIES, and REPOSITORY files in the CVS subdir of every project. 
  Is there a way to say "open this particular file in 'automode'" -- or 
do you have to explicitly open it in "rt" for reading, and reopen in 
"wb" for writing?  Because if you have to do that, then we might as well 
just open those particular files in "t" mode always...

CHANGES:

o updated to the 1.11.2 source
o requires gdbm-1.8.0-4
o NO new patches for textmode/binmode issues.  Please help.
o Surf to
   http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/release/cvs/
   and take a look at the results of my tests, in these files:
     cvs-1.11.2-1.check.localpass
     cvs-1.11.2-1.check.localfail
     cvs-1.11.2-1.check.remotepass
     cvs-1.11.2-1.check.remotefail
o There is also a more detailed summary of my experiments in the file
   CHECK.SUMMARY, but I've reproduced that below.
o I have not gone thru all of the recent (and not-so-recent) bug
   reports yet.
o I have made NO effort to get pserver working.  (Yes, I remember that
   somebody has successfully done so, and that I need to include their
   recipe in the cygwin.README.  I have not yet done so.
o Autoconf wackiness (see below)

--Chuck

Table of contents:
   Notes
   Brief Summary of Test Failures
   Gory Test Results


For Extremely Gory Test Results, see the files
   cvs-1.11.2-1.check.localpass
   cvs-1.11.2-1.check.localfail
   cvs-1.11.2-1.check.remotepass
   cvs-1.11.2-1.check.remotefail

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

  (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 stackdump
      errmsg1 (subtest 168)
      binfiles3 (subtest 11)
      rcs2 (subtest 7)
      rcs3 (subtest 5)

      So, the 1.11.2-1 actually performs better than 1.11.0-1; it
      no longer fails the rcs2 and rcs3 tests.  Of the five :local:
      failures, four 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.

      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: passes join-readonly-conflict
        :fork: fails crerepos -- but that's expected

  (3) for whatever reason, 'join-readonly-conflict' fails in
      the local test, but passes in the :fork: (remote) test.

  (4) coredumping is bad.

  (5) local, stamps failed once, but running the test standalone
      passed.  Could be a race?
	
  (6) Wackiness with autoconf.  Although my configure.in and acinclude.m4
      seem to be bug free themselves, autoconf is generating buggy
      configures.  (I mean, it totally loses track of what it's doing,
      and puts in comments without '#' marks, drops 'help' text in the
      middle of the running script, etc.)  This is bad, and I'll report
      it to the autoconf list.  However, I have a "patch" of sorts
      that I can use to fix the errors after running autoconf --
      it's CYGWIN-PATCHES/post-autoconf-patch.  This should not be
      of any use to anyone, unless you start hacking the auto* files.

      You may not be able to actually APPLY the patch, but it shows
      you what errors happen, and approximately where to find them.
      (The human brain 'fuzzy patch' function is much better -- if
      slower -- than patch.exe's.)

      However, WATCH OUT for the auto-rebuild of the configuration
      files when you run 'make'.  Make sure you run autoheader and
      automake AFTER running autoconf and fixing up configure.

  (7) Special 'targets' in the build script. After doing
      cvs-1.11.2-1.sh conf, and build, you can also do:

        cvs-1.11.2-1.sh check-local-pass
        cvs-1.11.2-1.sh check-local-fail
        cvs-1.11.2-1.sh check-remote-pass
        cvs-1.11.2-1.sh check-remote-fail

      check-local-pass runs all 115 local tests that I got successful
      results for.  Ditto check-remote-pass.  However, check-local-fail
      and check-remote-fail run only the (5 each) tests that failed
      in my testing.
		

--------------------------------------------
       BRIEF SUMMARY OF TEST FAILURES
--------------------------------------------


FAILED TESTS:
   local, join-readonly-conflict (subtest join-readonly-conflict-10)

   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-148a0)
     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, crerepos
     ERROR: cannot test remote CVS, because `rsh KHELDAR' fails.
     when testing in remote mode, crerepos uses :ext: instead of
     :fork:.  Therefore, I expect to fail, because I didn't have
     rshd running.

--------------------------------------------
              GORY TEST DETAILS
--------------------------------------------

LOCAL TESTS

   FAILED 5
     join-readonly-conflict
     modules modules6
     binfiles3
     errmsg1

   PASSED 115
     version basica basicb basicc basic1 deep basic2
     files spacefiles commit-readonly
     rdiff diff death death2 rm-update-message rmadd rmadd2
     dirs dirs2 branches branches2 tagc tagf
     rcslib multibranch import importb importc
     import-after-initial
     join join2 join3
     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

REMOTE TESTS: (uses :fork:, not :ext: or :pserver:)

   FAILED 5
     modules modules6
     binfiles3
     errmsg1 crerepos

   PASSED 115
     join-readonly-conflict
     version basica basicb basicc basic1 deep basic2
     files spacefiles commit-readonly
     rdiff diff death death2 rm-update-message rmadd rmadd2
     dirs dirs2 branches branches2 tagc tagf
     rcslib multibranch import importb importc
     import-after-initial
     join join2 join3
     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
     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







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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-06-18  7:53 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-17 12:55 cvs-1.11.2 test release Phil Dempster
2002-06-17 13:15 ` Charles Wilson
2002-06-18  4:59   ` Phil Dempster
  -- strict thread matches above, loose matches on Subject: below --
2002-05-19 22:14 Charles Wilson
2002-05-20 22:37 ` Charles Wilson
2002-06-15  4:20   ` Charles Wilson
2002-06-15 14:50     ` Nicholas Wourms
2002-06-15 16:31       ` Charles Wilson

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