Re: cvs problem

On Fri, 5 Oct 2001, Lamar Owen wrote:


> 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'm on several PG lists (and many others). I do entirely enough reading already.
And I don't read as quickly as you do.


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

I made it clear I was getting frustrated. Read in that context, I think it was
pretty mild;-)


Especially considering the point I saw a project in disarray (and I don't think anyone's
disputed that).




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

I'm prepared for the project itself breaking my data - that I expect is likely to happen.

Each time I do a CVS update, I rebuild my binaries and database.


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

I'm ingnorant. I don't see why CVSROOT would need to be changed. I thought
Unix filesystems were flexible enough to allow CVS to see things as they really aren't,
perhaps using symlinks.

And if one project does change it, I still don't see how that justifies another.

> that I track with CVS.
>
> Just a momentary pain, really.

From what I can tell, completely unnecessary. And until somone explains why itwas necessary, then I won't understand
it.


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

Is Marc part of the team?


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


And this is the first time someone has bothered to tell me, and it's weeks since the problemarose and I reported it (I
hadfigured it out and got a new checkout).
 

Instead of telling me how to go on with my affairs, there ensured a discussion about the documentation being
wrong, about the devlopers corner shouldn't really be there and so on.

And replies to my problems enroling in these lists were no more helpful. I wanted to get on the
list because I felt I wasn't seeing all the relevant discussion of other problems, and in particular
what was broken wrt CVS.

Now, I've always thought that the first thing to do when someone has a problem is to give them the solution
to their problem if the solution is easily had.

In those two cases it would have taken someone a minute or two to say, Sorry 'bout that. Do this.'

To be sure if the Postgresql itself is broken, that may take longer, but that wasn't the case. The procedures
(from my point of view) or documentation (from yours) was wrong, and what I needed most was the knowledge
of what actually works.

And referring me to the incorrect documentation didn't serve to persuade me the project's
running well.