On Wed, 8 Feb 2006, Kevin Kilzer wrote:
"[..]
You suggest that some of these questions are the responsibility of
"management", so I should tell you that I am that manager. I am
setting (actually resetting), ground rules in a small, growing, design
team."
I wish you success for this.
" I have been blessed with a VHDL designer that can't seem to
grasp the idea of [..] version
control."
I have edited the quotation with "[..]" not because the omitted items in
the list are unimportant -- they are important -- but because others have
already answered you about them.
Version control is important. A VHDL colleague is quite obsessed with it,
and I have certainly found it useful when using CVS (
WWW.NonGNU.org/cvs/
) that when I check in a new revision of one of over thirty files (for a
small one-man codebase with 959 lines with semicolons), I can document it
better because after so much typing I have at least once forgotten at
least one of at least two major changes but CVS pointed this out to me so
that I documented it better than I would have without a revision tracker.
CVS is not the only tool suitable for tracking changes, but it is the only
one I have used. For a completely new project, it may be worth considering
Subversion (
http://subversion.tigris.org/ ) instead as it is used for GCC
now instead of CVS but many of the alleged improvements will not affect
the early adoption of the tool. Of course, a defiant person might use
preferring to use something which is really easy to learn as an excuse
so perhaps a commercial version control system would be worthwhile. CVS
and probably most others are language-independent, so if your other
software personnel (you and the VHDL employee seem to be under the
misimpression that writing VHDL source code is not writing software)
already use a versioning tool, make the VHDL person use that. That way,
they can check whether he is committing revisions with something other
than a blank comment, they do not need to understand any VHDL to spot
this kind of cheating.
Many versioning tools are discussed in the discussion "CVS or SVN ?!" on
http://lists.gnu.org/archive/html/avr-gcc-list/2005-09/threads.html
and
http://lists.gnu.org/archive/html/avr-gcc-list/2005-10/threads.html
Mentioned in two of those emails, is a still incomplete list of different
versioning tools at
http://better-scm.berlios.de/comparison/comparison.html
If CVS is chosen, instead of starting with the manual, I recommend from
first hand experience reading
http://cvsbook.red-bean.com/ and it took me
probably less than a month from starting this free book to starting a
project very well with CVS.
" The remainder of the design team is software, so the VHDL
guy thinks he is special.
They way he moans about recording design information, I was starting
to wonder if I was the demon here, or that VHDL guys really are
special.
"
Such arrogance and snobbery towards software people is common in hardware
people, though fortunately not where I am currently based. I have never
had to work with a hardware description language user like this, but I
used to work with a hardware (diodes and resistors etc. with CAD) person
who naively and incorrectly believed that the laws of logic and the laws
of Nature change if you remove functionality from software and transfer
it to hardware: he would do this and eventually find that his attempted
solution was even worse than the original software and revert the
responsibility back to the software developer (i.e. myself).
" I see by your answers that my concerns are justified."
Definitely.
"One of my fears is that the answer to "how many files?" will be "one",
strengthening the notion that the guy is just a hacker.
[..]"
There should be many more than just one file because in a well designed;
loosely coupled; and cohesive sourcebase, intelligibly tracking
(reviewing) changes later can be difficult if the only file changed each
time is the same file because it contains everything.
Regards,
Colin Paul Gloster