[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: $Name $ in branches
Greg A. Woods
Re: $Name $ in branches
Thu, 19 Apr 2001 19:44:26 -0400 (EDT)
[ On Thursday, April 19, 2001 at 16:12:25 (-0500), David D. Hagood wrote: ]
> Subject: $Name $ in branches
> I disagree with Mr. Woods on this: adding the branch ID to a build makes
> sense in my environment: I have several developers, each working on
> their own branch of an embedded system. As needed, the load their code
> into target systems for development. Since the number of developers is
> larger than the number of target systems available to do development on,
> there needs to be some reuse of the systems. Being able to quickly
> identify that "Oh, this unit has Bruce's build, therefor I should
> contact him about this" would save a great deal of time.
Huh? Why doesn't the $Author keyword (part of $Id, BTW), work for you
Or are the developers each checking out the entire project on their own
branch, working on some random part of it, and then plugging a
sub-product that may have been built from changes by many separate
developers into a common/shared test environment?
In either case though it would seem that your process is fatally flawed
(at least from a release management perspective).
> Also, this would allow the software to automatically maintain unique
> setups across different development branches. Sometimes I want MY setups
> to be different from Bruce's, or I need to unit to access MY section of
> the server, rather than Bruce's. Again, if I can generate this
> automatically it saves an error prone step.
Still it would be of enormous benefit to force developers to create mini
releases of anything and *everything* that goes onto a common test system....
>From a higher-level release management perspective there's NEVER any
excuse for letting something out of a developer's direct control
(i.e. into an environment where its origins and status must be
identifiable) unless it's been properly "released". In CVS this is most
easily done by simply tagging the code to be released and using "cvs
export -kv" to create a copy that can be compiled such that the
resulting products can be shared. You don't have to keep the tags
forever -- only so long as the released product exists in any place
where it needs to be identified. The $Name keyword will work
*perfectly* for this since that's the way it was "designed" to work in
In fact in CVS this kind of release management is so trivially easy that
there's not really any excuse for avoiding it. All you need to do is
define a release tag naming scheme, give everyone five minutes of
training, and carry a big stick to reinforce the training....
Proper release management reduces errors and saves one from many
headaches. You can't really use any version control system effectively
in a multi-user development environment without doing proper release
Note also that this automatically gets rid of the issue of un-committed
code going into a "public"/shared/common test environment where its
origins might need to be identified.
In fact now that I think about it, this is perhaps your central problem
right there. You're letting developers test un-committed code on shared
test systems. This isn't really an effective way to use version
control. You have to freeze changes *before* you share them in any way!
Remember that you can't do effective QA without having a proper release
management policy and without doing some level of change control.
Release management is what allows you do identify what exactly you're
testing in the QA phase of your development process. CVS itself can
only help do some of this stuff at a very low level.
> Additionally, I have to deal with marketing types who frequently come
> into the lab and stea..., er, borrow units to take to customers.
That's a management issue, not a CVS issue! ;-)
Big sticks, commonly called "clue-by-4s" in B.O.F.H. circles, might help
here too! :-) Every repository manager needs B.O.F.H. training! ;-)
As for letting the marketing types get away with such shenanigans, well,
"You create the circumstances you must live with."
> Actually, what I'd really rather see would be a $Branch$ or something
> that would allow me to contain that information.
You can't really do that without changing the RCS file format! :-)
(of course this would be a relatively trivial and innocuous change and
could be done in a relatively compatible way, though full
ineroperability with other RCS tools would not be possible.)
Greg A. Woods
+1 416 218-0098 VE3TCP <address@hidden> <address@hidden>
Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>