Re: $Name $ in branches

[Greg A. Woods]

[ On Friday, April 20, 2001 at 08:49:34 (-0500), David D. Hagood wrote: ]
> Subject: Re: $Name $ in branches
>
> Because I often have developers working on several different "things" at
> once. For example, I may be working on signal processing, and in a
> seperate branch working on UI. Using the author keyword gives me no way
> to seperate this, even though one branch is david_dsp and one is david_ui.

Hmmm... sounds like you've also got some "confusion" between branches
and modules.  If that's a real example, why would UI and DSP be in the
same module but on different branches?  Shouldn't they be separate?

Perhaps what you're really doing is using separate working directories
for each "thing" (and confusing that with branches because each working
directory is also on its own branch).  That's sort of good, as far as it
goes, but you're still missing an important step (which I'll get to in a
round-about fashion).

> This is an embedded system. Much of the work is in hardware->software
> integration. You have to go back to the lab and see if the hardware is
> actually going to do what the documentation says it should do. Then you
> fix your code to take into account what actually works.

I am indeed fully aware of how embedded systems development works and I
have direct experience at both working within environments doing
embedded systemd development and at designing software processes to be
applied within such environments.  My twenty-odd years of experience in
software isn't solely in those fields though....

>  > In either case though it would seem that your process is fatally flawed
>  > (at least from a release management perspective).
> 
> You assume "releases" are king. I do on average of twenty builds a day
> while trying to get the software and hardware to work together. I don't
> want to pollute my tagspace with twenty tags a day per developer.

Information is not pollution.  :-)

But each "build" doesn't have to be a separate release either.

Besides I think I mentioned that these tags don't have to be
permanent....

> I don't want to have to do a cvs tag && cvs update && build && and load
> cycle because I found that I have to wait 20 uSec after clearing ctrl4
> before I can start the DMA, even though the HW guy says I don't. I want
> to change the code, build that sub-module, verify my fix, commit the
> change to my branch, and move on.

I was assuming, perhaps mistakenly, that only tested code would be
committed and thus only committed *and* tested code would be "released"
into any environment where it would require "identification".

I think what's really important here is to understand that code should
never be put into a scenario where it might need to be independently
"identified" without "freezing" it in your version control system.  You
can't hatch a chicken without first laying an egg.  If un-committed
changes ever get out of the direct and sole control of the developer
working on them then there's no possible way to identify them in any
product or sub-component at any later date and not even any way to know
if they've ever been committed.  The actual mechanisms of how you go
about making sure that only committed changes are ever shared in any
ware are of course specific to your environment, and whether each change
set goes through a formal or semi-formal "release" process is also
dependent on your specific requirements.

The reason I said you might need a big stick is because you'll have to
"re-train" people so that they follow the process properly and so that
they don't "leak" unidentifiable products out into scenarios where their
heritage might actually be relevant.  If you can't do that then you
might as well not use a common version control system but just let each
developer manage their own version tracking in their own private manner
since they'll really be the only people who can identify their products
anyway.

Presumably if an individual developer implements a specific change set
he or she should be able to take it through the edit-compile-test cycle
without it leaking out into the hands of either QA people or the
marketing department, or (heaven forbid) actual end users.  Once the
individual developer is happy with that change set then it should be
committed to the repository.  If the next step is to build a module
(i.e. some sub-component) including those changes so that it can be
handed to the QA department, or integrated into the baseline of some
encompassing component, then a "release" should be made.  Depending on
what point you're at in your overall development process that "release"
might be a very temporary marker that'll simply slide up when the next
change set is ready for integration/testing/whatever.  Each change set
might even be re-tagged as it goes through various stages before it
makes it into the baseline product.

Unfortunately CVS isn't really well suited for a rigorously engineered
software development process like this.  All it offers are tags,
branches, and modules and sometimes that stuff doesn't map well to the
process you're actually trying to manage.

Not all projects can afford to have sufficient staff and prototype
systems to be able to separate out various stages of development and
integration either.  That might mean that developers might have to be
extra vigilant to make sure their private tests don't accidentally get
integrated into something someone else is testing.  That implies that
integration testing should be a separate phase, but that brings us back
to possible resource limitations that might prevent proper separation of
software development phases.

It sounds like you're actually not that far off from having a successful
process to manage your development.  It's just that you don't seem to be
very successfull yet at preventing un-marked code from leaking out into
scenarios where it may become necessary to identify again.

Perhaps even if you're able to just make two relatively tiny changes to
your process you'll be able to carry on without too much pain:

        1. make sure no code is ever gets away from any developer without
           first being committed to the repository

        2. make sure that every file contains an expanded $Id keyword
           in some way and that any "compiled" products contain copies
           of all of the expanded $Id keywords from all of the
           components used in the "compilation" process

That way even though you can't easily identify the branch name you'll
still be able to re-create any given product from the specified versions
of each of its components (and thus be able to identify when a product
has been created from some component that was not committed should the
re-created product not exactly match the one being identified).  You'll
also be able to discover the branch name by matching the specific RCS
version numbers with branch tags reported by "cvs log".

This is finer grained control than you originally requested, but I think
it's far better than just identifying changes by what actually amounts
to which working directory they came from.

> My project is designed as small, self-contained modules so that I can
> better parallelize my development cycle.

Uh huh.  But what's that got to do with your problem?  In theory good
modularisation should only make the adjustments I'm suggesting for your
process easier to apply!

>  > As for letting the marketing types get away with such shenanigans, well,
>  > "You create the circumstances you must live with."
>
> Perhaps you work in an environment where your word is law.

That little quote doesn't necessarily have the implications you seem to
think it does -- it's much more subtle than that, especially in team
environments!  ;-)

> I tell you what. If you are ever in Wichita, KS, and have a day to burn, 
> stop by the plant. I will show you what I do, and why I do it. Then, if 
> you can show me a better way, I'll not only listen, but see if I can get 
> HR to make you an offer.

I really would love to do that!

Unfortunately I don't get down that way very often (and I've never been
to Kansas as far as I can remember, alas).....

-- 
                                                        Greg A. Woods

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