[ On Wednesday, February 16, 2000 at 14:57:26 (-0600), David Thornley wrote: ]
> Subject: Re: CVS File Locking
>
> > Such recreation of changes is a perfectly valid solution. Nothing needs
> > to be lost of given up.
>
> I suddenly feel like I'm in an alien universe. Certainly you're aware
> that this is the standard solution in (say) a SCCS or RCS conflict
> that's not caught in time. If you think this is a perfectly valuable
> solution, then why do you like CVS? You can do concurrent development
> with no tools at all, if you don't mind this sort of "merge". I did
> it for quite a few years. I hated it when it went wrong.
Wow. I think you completely missed my point. Perhaps because you don't
yet deeply understand what "concurrent development" really means.
One uses CVS only as an optimisation to having incredibly large numbers
of conflicts that need manual resolution (where "resolution" can mean
anything from manual merging to redoing one of the changes or even
tossing both changes).
One does not avoid CVS, or wish for locks in CVS, if one understands the
true advantages of concurrent development even if on occasion there will
be the odd conflict that requires manual resolution.
> So you think that "cvs history" is the ideal way of learning "who might be
> working on the same module that you are"? That seems odd.
It is.
> I don't
> think "cvs history" is the ideal way of learning anything, the way
> the output is formatted.
It isn't. :-)
> And, if you're working to a strict copy-edit-merge paradigm, what do
> you care about what other developers are doing? The only reason
> you'd want to know is if you wanted to coordinate changes with them
> - in other words, if you wanted to add some serialization to the
> development.
Exactly. CVS is not a substitute for project management.
> And the question arises of why CVS shouldn't handle some sort of
> lock. It isn't a tremendously difficult thing to implement, and
> would not significantly increase code size and complexity.
Others have answered this several times, as have I. You can't have your
cake and eat it too.
> Let me put it this way. What I completely fail to understand is why
> it has to be one way or the other. Locking is fairly easy and economical
> to implement. It is an easy way to control serialized development,
> and with some files there is no alternative to serialized changes.
Perhaps in some other tool, but not in CVS.
> I have been trying to find out why you think CVS is, and must be in
> the future, used for copy-edit-merge development and nothing else.
> Such strictness would make CVS undesirable in some situations where
> it could otherwise be used very effectively.
No, it's what makes CVS an attractive *tool*. It does one thing right
(well, that's the goal, anyway).
If there really were a place for a one-button tool then someone would
have implemented it already. Hmm.... maybe they have!
> Relaxing the strictness
> would not cause noticeable code bloat.
It will, but that's not entirely the point.
> It would have the evangelical
> advantage of getting CVS used by shops that otherwise would go to
> a strictly locking system, and opening up the possibility that the
> users will find that they can get more work done with concurrent
> development.
Real CVS users don't want to see CVS used in shops that would otherwise
require strict locking. Please don't let them get their hands on it
unless they are willing to change their ways!
> > The issue in my mind isn't one of a conflict between concurrent
> > and serialised development. That's already been decided in favour of
> > the former as far as I'm concerned.
>
> When it works. It doesn't always.
Now I know for sure that you don't deeply understand the concurrent
development paradigm.
It *ALWAYS* works, by definition. It's simply a matter of effort. CVS
advocates have found that despite what false intuition might hint at
concurrent development is actually less effort overall.
> There are a lot of reasons for working in technically deficient
> environments. You may well refuse to work in such, and you may well
> get away from it. There are a lot of people who have the independence
> to work only in the environments that please them. There are also
> a lot of people who work in environments that don't, because that's
> where the paycheck is and there are people besides them depending on
> that paycheck. I've been in that position, and I have a great deal
> of sympathy for those who are.
I have zero sympathy for people who have put themselves into positions
of using tools that they can't stand and yet still stay using them.
> This strikes me as an extremely selfish point of view.
Well yes, of course it's selfish. Fortunately I'm far from the only
person with the same point of view, or otherwise I'd be creating a whole
lot of work for myself.
> If somebody were to add locks to CVS, how would it affect you?
It would cause me to have to rip them out again.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
