Re: $Name $ in branches

[David D. Hagood]

address@hidden (CVS-II Discussion Mailing List) wrote:


> Huh?  Why doesn't the $Author keyword (part of $Id, BTW), work for you
> then?
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.

Perhaps for some of my junior programmers, who I don't load down with
more than one task, $Author$ might work.


>
> 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?
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.


>
> 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. 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.

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



>
> 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....
No, for the reasons above.


>
> 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".
That's not what's happening. Please don't criticize my development
methodology without working here. The embedded software development
cycle is different from applications development. In apps development,
you change something, build and test on your system, and iterate. In
embedded development, you MUST test on the target hardware. Now, I'd
love to have a target system for each developer, but that won't happen.
Furthurmore, there is the isssue of loading the code onto the systems. I 
want to automate that, and for various reasons it would be useful for me 
to have the branch ID.

Unless you have more than two decades of embedded/realtime software
development experience, please don't lecture me about how to do it. I
welcome real, actionable, useful advice, but it seems to me that the 
tone of your posts is more condecending than helpful. Rather than 
telling me that my methodolgy is all wrong (without knowing what my 
methodology is, or why it is as it is), you could simply have said "you 
seem to be using $Name in a way that it wasn't intended".


> 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
> CVS.
Except that I must then do a fresh checkout to purswade CVS to update
the tags, then do a fresh build, then do a download. Then run for 30
seconds, swear, and begin again after changing one line of code.


> 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. If so, 
congratulations. I, however, don't. So, I have to do what I can, within 
the context of the powers my position gives me, to solve what problems I 
can. Believe me, I am working on correcting this problem, but that is 
outside the scope of this discussion, so suggestions that I do so aren't 
really actionable.

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.