Re: cvs problem

On Thursday 04 October 2001 09:40 pm, John Summerfield wrote:
> Well, remember I only arrived here in the past two weeks. What I've seen
> has not been reassuring.

May I be so bold as to suggest your taking a few hours of your time and
reading the last six months to a year of the list's archives? :-)

I did just that a little over two years ago when I (somewhat rudely, I may
add) grabbed the RPM bull by the specfile horns -- I read the previous two
years of archives to get a feel for the culture of the group first. As I
can read 1200-1600 words per minute, I'm able to process 10-15k messages per
day easily. (My daily load is right now around 1k messages per day, along
with all my other broadcast engineering related work). 1k messages takes a
little over half an hour.

> It's hard to believe there's a serious effort being made to fix a problem
> when all the effort I can see has no apparent relationship to the problem.

The interdependencies run deep into areas that appear unrelated to the
problem at hand.

> I don't think I was being rude. It's true I'm no diplomat. I've criticised
> actions (and, I think, with considerable justice), but I've not actually
> criticised people.

'You'd better get your act together fellas' was just a tad too critical for
my taste, sorry. I'm not known for being a diplomat either.... I've seen
real flamewars, too, and your message was certainly not a flame, but just a
tad too critical. Had I considered it a flame I wouldn't have bothered
replying.

> And my point is that something moved. Something that many people (I don't
> know how many, but thousands wouldn't surprise me) depended on.

> That experiece tells me that making a change that inconveniences
> users is a mistake.

Too much backwards compatibility is also a mistake. If a person is tracking
the bleeding-edge CVS, they are already having to watch for initdb-forcing
changes -- a CVSROOT change is small potatoes compared to an initdb-force --
which happens _often_ during the development cycle. There are other major
changes that happen -- to the point where a fresh checkout might even be
necessary, so that leftover files from previous local builds aren't present.
That's just a part of using CVS, in my experience.

And this is not the only open source project that has changed CVSROOT on
people -- in fact, this one has changed less than any of the other projects
that I track with CVS.

Just a momentary pain, really.

> From my other readinds I see that the PG team controls the entire disk
> layout. Given that, I can see no reason that the CVS tree needed to be
> changed in the way it was.

Correction: Marc Fournier controls the entire disk layout, as it's his
server. It was his decision to change the layout.

> I still think it should be made to work the old way; both ways, now, as
> there are people who depend on both structures.

All you have to do to use the new layout is to blow away your checkout, login
again with the new layout, and run another checkout. It doesn't take long to
do. And it is now documented again, AFAIK.

It's a little more complicated for CVSup users, though. And that's where
Thomas (our resident rocket scientist) had his beef, along with the
documentation build process, etc. When docs build automatically, and you
change the source document to reflect a change, but the build fails due to
that very layout change, it can get pretty ugly. And that's exactly what
happened, from my perspective.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11