Re: cvs-1.11.2 test release

Re: cvs-1.11.2 test release

[Phil Dempster]

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/

Re: cvs-1.11.2 test release

[Charles Wilson]

Phil Dempster wrote:

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


That's an setup issue.  You can run cvs as a standalone daemon -- 
without inetd -- on linux, too.

(BTW, :pserver: and :ntserver: and inetd/standalone daemon server 
support is a future goal, not an immediate goal. The immediate goal, 
after appropriate discussion and testing here, is to get a 
cvsnt-on-cygwin package that works *as well as* and *totally plug-in 
replacement compatible with* the current cvs-on-cygwin package.)

Then we worry about additional features.

--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-1.11.2 test release

[Phil Dempster]

> > 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).
>
> That's an setup issue.  You can run cvs as a standalone daemon --
> without inetd -- on linux, too.

True enough.

> (BTW, :pserver: and :ntserver: and inetd/standalone daemon server
> support is a future goal, not an immediate goal. The immediate goal,
> after appropriate discussion and testing here, is to get a
> cvsnt-on-cygwin package that works *as well as* and *totally plug-in
> replacement compatible with* the current cvs-on-cygwin package.)
>
> Then we worry about additional features.
>
> --Chuck

Agreed.

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

cvs-1.11.2 test release

[Charles Wilson]

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/

Re: cvs-1.11.2 test release

[Charles Wilson]

Bump to 1.11.2-2.  I've fixed the autconf hackery, so it works correctly 
now.  Thanks to Akim Demaille from the autoconf list for pointers...

All of the original warnings, provisos, etc apply to this "release". 
Refer to the first message in this thread for more info.

--Chuck

FIXED:

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




--
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-1.11.2 test release

[Charles Wilson]

Withdrawn.

(a) I've found a few bugs with this release

(b) in attempting to push upstream the patches our version of cvs has 
been using for the past 18 months, I encounted stiff resistance.  Okay, 
not actually resistance -- just utter apathy.  It seems that for all 
intents and purposes the official cvs tree is NOT undergoing any active 
development.  I received a suggestion to look into cvsnt -- which has 
now been backported to unix and is no longer a "windows only" port, as 
of Feb 22, 2002.

This sounds like a good idea.  In the long term, we should be able to 
leverage the cvsnt support for
   1) :pserver: running as a standalone service under LOCALSYSTEM, or 
from inetd(?).
   2) :ntserver: protocol, which uses NT authentication directly to 
change user contexts, when operating within an NT domain
   3) active development

Short term, I would like to create a "port" of cvsnt that compiles under 
cygwin, and provides absolute compatibility with our cvs-1.11.0-1 
package.  For now, I'm not worried about :pserver:, daemon operation, 
:ntserver:, etc.  Just the basics -- which is what we have working now 
with 1.11.0-1.

This means I need to cross-port our local cygwin changes, including the 
gdbm database support for modules and val-tags in CVSROOT.  The good 
news: the cvsnt guys probably LIKE to receive patches.

Since the cvsnt port is currently based on 1.11.1, I will probably 
package the cvsnt version as "t4est: cvs-1.11.1-X" and NOT 
"cvsnt-1.11.1...".  It might be a little confusing ("What?  'cvs' is not 
cvs?  It's cvsnt?") but this course of action would lead to far fewer 
upgrade/downgrade problems in the long run (think: cvs-1.11.0-2 == 
empty, cvsnt-1.11.1-1 conflicts with cvs-1.11.0-1, no way to revert 
back, etc)

Comments?  Questions?  Does anyone have experience with a *cygwin* port 
of cvsnt (not just using the native cvsnt from within cygwin)?

--Chuck


Charles Wilson wrote:

> Bump to 1.11.2-2.  I've fixed the autconf hackery, so it works correctly 
> now.  Thanks to Akim Demaille from the autoconf list for pointers...
> 
> All of the original warnings, provisos, etc apply to this "release". 
> Refer to the first message in this thread for more info.



--
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-1.11.2 test release

[Nicholas Wourms]

--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> Withdrawn.
> 
> (a) I've found a few bugs with this release
> 
> (b) in attempting to push upstream the patches our version of cvs has 
> been using for the past 18 months, I encounted stiff resistance.  Okay, 
> not actually resistance -- just utter apathy.  It seems that for all 
> intents and purposes the official cvs tree is NOT undergoing any active 
> development.  I received a suggestion to look into cvsnt -- which has 
> now been backported to unix and is no longer a "windows only" port, as 
> of Feb 22, 2002.
> 
> This sounds like a good idea.  In the long term, we should be able to 
> leverage the cvsnt support for
>    1) :pserver: running as a standalone service under LOCALSYSTEM, or 
> from inetd(?).
>    2) :ntserver: protocol, which uses NT authentication directly to 
> change user contexts, when operating within an NT domain
>    3) active development

Chuck,

This sounds all good and fine, but I am faced with the following issues
(after a *brief* scan of the cvsnt webpage):

A)Most projects use CVS, why the hell would the development of the CVS be
dead?  Forgive me assumptions, but I thought the CVS project was one of
those key GNU projects?  Or is everyone migrating to subversion now?  It
seems like patches are being applied to the tree and some work is being
done.  Perhaps you should apply to become a member of the CVS project so
you can just import your patches on your own.  This apathy concerns me
greatly from both a linux and cygwin standpoint.  I usually welcome
change, but I think sticking with the tried and true CVS might be a good
idea.

B)CVSnt on Windows seems to be nt/2000/xp-centric, what pitfalls can those
of us running ME/9x expect?  (This may be a question for those who have
tried the cvsnt on cygwin

C)Will it be MingW or native Cygwin based?  Although you did hint about
unix support, you didn't mention this explicitly...

D)Is there any functionality in the current Cygwin CVS that CVSnt wouldn't
be able to provide?  (I.E. SSH, etc.)

Forgive these flurry of questions, but I feel compelled to ask for myself
and undoubtly for others, as well.  I believe, no matter what, that you'll
arrive at the appropriate decision.

Cheers,
Nicholas

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
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-1.11.2 test release

[Charles Wilson]

Nicholas Wourms wrote:

> This sounds all good and fine, but I am faced with the following issues
> (after a *brief* scan of the cvsnt webpage):
> 
> A)Most projects use CVS, why the hell would the development of the CVS be
> dead?  Forgive me assumptions, but I thought the CVS project was one of
> those key GNU projects?  Or is everyone migrating to subversion now?  It
> seems like patches are being applied to the tree and some work is being
> done.  Perhaps you should apply to become a member of the CVS project so
> you can just import your patches on your own.  This apathy concerns me
> greatly from both a linux and cygwin standpoint.  I usually welcome
> change, but I think sticking with the tried and true CVS might be a good
> idea.


The following is a quote from the HACKING file in cvs:

> It is neither practical
> nor desirable for all/most contributions to be distributed through the
> "official" (whatever that means) mechanisms of CVS releases and CVS
> developers.  Now, the "official" mechanisms do try to incorporate
> those patches which seem most suitable for widespread usage, together
> with test cases and documentation.  So if a patch becomes sufficiently
> popular in the CVS community, it is likely that one of the CVS
> developers will eventually try to do something with it.  But dealing
> with the CVS developers may be the last step of the process rather
> than the first.


And no, this ^^^^ is not boilerplate.  They really mean it.


Also, there were about two years between 1.10.8 and 1.11.0.  In the past 
18 months, there have been two additional releases: 1.11.1 and 1.11.2. 
That's pretty slow development.  From the attitude on the list, I'd 
guess that those releases were motivated by a desire to push changes the 
core developers themselves had produced -- not to incorporate patches 
"from the wider community".  Apparently, FreeBSD had been trying to get 
them to merge changes for years and finally gave up


The fact is, "cvs" is a fairly stable package.  There are few bugs, and 
they are unwilling to accept large patches (or even small ones) that MAY 
destabilize it merely to allow compilation/operation on "extra" 
platforms.  They would prefer that "odd" platforms (like cygwin) 
continue as forks, to protect the integrity of their "core" code.  Well, 
I'm tired of maintaining a fork.

The changes needed to run as a daemon on NT/cygwin -- and merely to 
*run* as a native NT port -- are far more intrusive than they want.


> B)CVSnt on Windows seems to be nt/2000/xp-centric, what pitfalls can those
> of us running ME/9x expect?  (This may be a question for those who have
> tried the cvsnt on cygwin


Remember, cvsnt code is almost entirely cvs code.  When compiled as a 
unix app, currently all the special nt-isms are #ifdef'ed out; you only 
get the bugfixes (that the cvs folks haven't merged).  So, at first, 
there would be no difference on NT/2K/Xp and 9x/Me -- except those that 
we already know about such as FAT vs. NTFS.

Later, as we start "turning on" some of the cvsnt-specific code, 
additional differences MAY crop up in the daemon-mode code; you may not 
be able to run a :pserver: or :ntserver: daemon on 9x/Me -- but the 
cygwin kernel serves as a great "leveler", so we'll be able to 
(hopefully) minimize those differences.


> C)Will it be MingW or native Cygwin based?  Although you did hint about
> unix support, you didn't mention this explicitly...


cygwin.  NOT mingw.

> D)Is there any functionality in the current Cygwin CVS that CVSnt wouldn't
> be able to provide?  (I.E. SSH, etc.)


TBD.  There are reports of difficulty using cvsnt + cygwin-ssh, but 
that's (a) a "mingw" cvsnt.  (b) perhaps not representative of the 
universe of experience -- only those folks who can't get it to work 
bother to post...

Otherwise, the codebase is basically cvs, so I'd be surprised if there 
were big problems.  There may be small wrinkles that we'd need to smooth 
out...


> Forgive these flurry of questions, but I feel compelled to ask for myself
> and undoubtly for others, as well.  I believe, no matter what, that you'll
> arrive at the appropriate decision.


Understood -- this is a big change to a core tool; I don't want to do 
anything precipitous or without community support.  Rest assured there 
will be a long 'testing' period before the (current) cvs-1.11.0-1 
package is retired.

--Chuck

FYI -- out of email contact until Tues...



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