delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/06/15/09:37:12

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
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: <3D0B4305.5080100@ece.gatech.edu>
Date: Sat, 15 Jun 2002 09:37:09 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
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: Nicholas Wourms <nwourms AT yahoo DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: cvs-1.11.2 test release
References: <20020615123723 DOT 67885 DOT qmail AT web21001 DOT mail DOT yahoo DOT com>


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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019