Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3CE83154.3030202@ece.gatech.edu> Date: Sun, 19 May 2002 19:12:20 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: cvs-1.11.2 test release Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/