Re: cvs checkout problem (Update to previous msgs and hopefully clarifications)

[Greg A. Woods]

[ On Thursday, February 21, 2002 at 11:18:43 (-0800), Terry Spafford wrote: ]
> Subject: cvs checkout problem (Update to previous msgs and hopefully 
> clarifications)
>
> Due to the nature of our customers and the fact that once a system gets 
> up and running on the customer site we rarely have easy access to it any 
> more, we have given up trying to keep code in synch between customers, 
> or with customers and new development. Most of the time, the only 
> changes we get to do for a system once it is installed is a bug fix the 
> customer requests. Since we only have about 20 customers or so (give or 
> take 10) at any one time, and since our product at the moment is 
> actually quite stable (due to 20-some years of development), this hasn't 
> been too much of a problem so far. (I know it'll bite us in our butts 
> eventually though. :)

In other words you have no real release management at all.  You seem to
go on building code, and then when you get a customer you install what
you have on the customer's system, and get it working for them, and then
you go back to building your code on your own machines.  Occasionally it
seems you go and make a bug fix for a customer, or build them a new
feature in their customized copy of a code tree that was in effect
branched off from your main development at some time in the past.  (of
course maybe the code still lives on your machines and only the product
files are installed on the customer machines, but in effect there's no
difference w.r.t. the methodology)

This is very much the kind of distributed development that's happened to
much freeware over the years, and in some senses very much like what's
been happening with the many GNU/Linux distributions, with the only main
difference being that in the freeware world there are many independent
developers and occasionally they send some/all of their changes back to
the core developers who may or may not integrate some/all changes to the
central code tree.  There are many code repositories, and perhaps even
multiple "main" repositories.  It all takes a lot of manual effort and
there's no real process or control.

CVS does not work in such situations.  CVS is designed to manage a
single central the code repository so that everyone works from the same
master repo.  It only allows branches within the existing files so that
changes to variant versions can be tracked, but given the strict tree
structure to the branching mechanism (no arbitrary graphs!) you usually
end up having to use branches only for one kind of variant, and normally
this means release branches, and not trying to use branches for OS and
porting variants (which are better managed with compile-time flags), nor
for customer branches (which are better managed with run-time flags).

BitKeeper (by BitMover.com) was designed to help out in these kinds of
scenarios, to help integrate version control and even give some release
management and bring some sanity on this kind of development model.
Many repos for everyone!  Shared baselines and distributed lines of
development!

> As for why we want to specify directories where code goes, it is because 
> we have many more customers then we have Alpha's to work on, so Unix 
> boxes will often be set up to be more then one customer at a time 
> depending on which binaries are running.

You need to learn to separate the way you build and test components of
your system and the way you integrate those components into a complete
product and test that complete product.  You're currently doing your
development in perhaps the most primitive way possible!  It would be
almost impossible to layer any kind of real centralised quality
assurance onto your current procedures (at least as I've been able to
understand them so far).

Perhaps some of your problems could be sorted out if you could eliminate
some of your confusion over what working directories are and how you
mighe better use them.

You really can have many separate working directories, all sharing the
same branch of development, or several each on different branches.  You
should have personal working directories for every developer, perhaps
many per developer too, and you should have working directories in which
the release manager integrates changes from developers, and so on.  It's
very difficult to describe what you should be doing without learning a
great deal more about your code tree and without writing many thousands
of words of text -- a whiteboard and one-on-one discussion would go a
lot further (pictures being worth a thousand words each, as they say!).

> Thank you for your time, and your patiance.

Good luck with rationalising and modernising your development process!

I really do think your company needs some high-level expert assistance
though.  If you've got any budget to spend at all I'd strongly recommend
searching for someone who's done all this before to help you out, but be
prepared to turn your whole world upside down and essentially start
fresh.  The BitKeeper.com folks could certainly help, as might the
qef.com folks; though of course neither of them use CVS....  :-)

-- 
                                                                Greg A. Woods

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