This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ATTN: cvs maintainer] cvs 1.12.x


Dave Korn wrote:
On a slightly different topic, what is new in cvs 1.12 that you need?  I
haven't noticed (it's entirely possible they happened and I missed it)
any major revolutions in cvs in, oh, 8 years or so?

Well, there's the new `-X' option, which means "Don't do completely insane nonsense when importing a new project"... that one's probably worth having!

There's also proxy support. However, I got stalled on cvs -- I created a test package for 1.11.21 but it ran into objections from the list...


Here's one issue:
http://www.cygwin.com/ml/cygwin/2006-03/msg00668.html

Here's another:
http://cygwin.com/ml/cygwin/2006-01/msg01383.html
but I **think** this issue is/was fixed in the snapshots and the soon-to-be-released cygwin 1.5.20.


http://www.cygwin.com/ml/cygwin/2006-02/msg00175.html

I figured I'd promote 1.11.21 to current (MAYBE also rolling back the upstream change that annoys Eric Blake and Corinna so much) after 1.5.20 is released.

Then, that frees up the 'test:' slot for a go at 1.12.x.

=====
BTW, there's one other reason why I don't track cvs releases very quickly: long ago, I painted myself, and cygwin, into a corner. For a number of good reasons, the "standard" database modules don't work well for cvs on cygwin platforms: ndbm, dbm, etc. cvs uses the database functionality, if present, only to manipulate val-tags and and modules, in the CVSROOT directory in the local repository. Now, you could just use flat-files and not compile in any support for these databases, but many years ago I cobbled together a mechanism whereby cvs could use GDBM to provide this database support.


It was a very intrusive patch.

It was also soundly, and rather rudely, rejected: "cvs patches from outside the development team must prove themselves by being widely used and shipped by a major distributor"

Now, at the time I received that message, we (cygwin) had been using my patches for about three years, and cygwin has a pretty large installed base -- and almost everyone who installs cygwin uses cvs. But that didn't matter, cygwin apparently is or at least was beneath their contempt.

So I was doomed to maintaining our GDBM patches outside the tree in perpetuity -- because I can't remove that support now. If I did so, I would break existing CVSROOT/modules.db files!

Did I mention the patches are intrusive? And really really hard to forward-port to each new release (the patches NEVER apply cleanly; it's hand-merge all the way). So I find it hard to generate enthusiasm for repeating that painful exercise very often. 1.12 is a nightmare; it's about 75% done in my workspace...
=====


--
Chuck

P.S. I am a bit astounded at the plethora of [PING], [ATTN] and {Hey you, bozo!] posts within just a few hours. Not everybody reads the list all day long...some of us have jobs <g> and right now, mine is kicking my butt...

P.P.S. In response to the O.P., "We're just mean". Actually, I have long had reservations about moving from the 'Stable' release of CVS to the 'Feature' release (Q: what's the opposite of 'stable'?)

However, enough people seem to be using 1.12 without issue, and 1.11 really seems moribund (even more than typical for the glacially-slow development that has characterized the CVS project) that I'll consider it. But first 1.11.21.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]