Re: Locking support

[Greg A. Woods]

[ On Friday, August 31, 2001 at 16:15:31 (+0000), address@hidden wrote: ]
> Subject: Re: Locking support
>
> What crutches?  What's wrong with knowing that someone is working on a file 
> before making the decision to work on it yourself?  I am not advocating 
> locking, just warning.  In our group we find it useful to have to opportunity
> to confer with someone before making changes to a file they have decided to
> change.  This tends to be more important in OO languages then procedural
> languages because there is usually a 1 to 1 relationship between files and 
> classes.  

If you're doing full OO design and development your developers should
have a very good idea of who's working on what objects (and of course
object definitions should all be in separate files too), so there should
be even less likelyhood of any concurrent editing than there is in
procdural development (eg. where there are global variables, etc.)

However If you need (or even find it helpful for) your version control
system to "warn" you of concurrent edits then that is a very strong
indication of poor communications within your team, and/or an incomplete
or poor software process model.  In an OO environment I'd expect you to
have design tools to provide or facilitate this communications mechanism
(and whether they're paper trails, e-mail or similar electronic forums,
or more formal CAD tools, is irrelevant).

CVS is not a substitute for management, and CVS is not a substitute for
developer communication.

> Unfortunately, the Unix world is not the only world.  My company is currently
> trying to push GUI based PVSC on us.  We are resisting with all the might we 
> can muster.

"PVCS" or "PVSC"?  I.e. Polytron Verson Control System?  If so then PVCS
is not GUI-only.  Version 6.5 has four integrated UIs, including a full
command-line interface that can easily be program driven.

Maybe PVCS is the right tool for you!  Did you ever think of that?

(I used PVCS almost a couple of decades ago, and other than the fact
that it was quite immature back then, I really didn't mind using it.)

> Thus the "I don't know of" qualifier.  I write software for a living.  I 
> don't evaluate version control software.  

Any good mechanic has a great deal of familiarity with her or his tools.

> CVS was designed to...?  Geez thats a strong argument (not!).  Since when has
> what something was designed for been a criteria for its use, especially this
> long after it's initial inception.  If the only people who used CVS where 
> those using it for what it was initially designed for, I venture to say you 
> would probably be it's only user ;-)

Welcome to the real world.  CVS's design certianly does have strong
influence over its use and applicability!  After all that goal was
very successfully built into the resulting tool and in such a way that
working around it was hard to impossible.

Also, who's to say that this design goal is still not an important facet
of the current version of the tool.  Sure it's been watered down a bit
with stupid add-on afterthoughts, but everyone who tries to work around
the primary design goal of CVS has almost certainly encountered many
scenarios where they don't get full satisfaction as a result.

Finally are you really sure I'm the only person who finds concurrent
development to be an imporant aspect of any medium to large project?
I'd venture to say that *ALL* of the major users of CVS use it primarily
for its ability to support concurrent (parallel) development in
traditional source-code projects.  The *BSD projects leap instantly to
mind, but there are many other very large projects, both public and
private, using CVS primarily because of this ability.  To all of these
projects the client/server ability is still only secondary.

However personally as a mostly one-man shop I use CVS primarily only for
its ability to manage vendor branches (even though this is also only a
secondary feature of CVS and one with which there are MANY problems! :-).

If I were to lead a larger multi-person project I would almost certainly
choose either Aegis (if I had no up-front tool budget) or BitKeeper or
possibly David Tilbrook's QEF (if I could pay for a commercial tool and
support) as the project's version control tool.  These tools all offer
support for concurrent development, but with fundamentally different
process models than that offered by CVS.  Aegis and QEF provide a
two-phase commit with unit testing that ensures the project baseline is
always stable, and BitKeeper provides a "lines-of-development" model
which is ultimately lead to a two-phase commit too and which can also be
integrated into a full SCM with unit testing and bug tracking, etc.

I would only likely choose CVS for a larger project if all of the
developers already had a deep understanding of, and lots of experience
with, CVS in such projects.

> One of the things I like about CVS is that it doesn't try to be a complete
> source control package.  It allows development groups to taylor it to there
> needs and personal preferences.

Indeed!  On this we agree.  Perhaps though this means you should look
outside of CVS for the tools you need to facilitate inter-developer
communications!  :-)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>