Mail Archives: cygwin/2006/05/04/23:50:16
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/
- Raw text -