Version control and issue management solutions?
Patrick Rhodes
Patrick.Rhodes@asu.edu
Thu, 28 Dec 2000 12:11:57 -0700
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--Boundary_(ID_qSSoGxYgtt1f0pmNqYHmYg)
Content-type: text/plain
We have implemented a home-grown version for quite some time. See, the
catch is, even if you have a piece of software that automatically tracks
changes to files, it is not 'intelligent' enough to know what those changes
are. So, if things break, or if code is duplicated somehow (not an exact
match, but more in having code duplicate function), the software cannot
figure out which changes to keep. This must be done by an integrator (a
human one, that is). In other words, automation cannot determine 'intent',
it can only determine 'syntax'.
Now, if you have more than one person working on the same file, the
integrator is going to have great difficulty resolving issues within the
file as well. Just because it compiles, doesn't mean that it works. Just
because it runs with no runtime errors, doesn't mean that it works.
Somebody has to go in there and figure out how it works and try to fix it
when it doesn't work correctly (and it WILL break).
In addition, if you are party 'A' and you've made some changes to the file,
and party 'B' comes along and makes changes to the file, when party 'A' gets
the revisions, they will have to figure out what party 'B' did to the file
unless party 'B' was absolutely careful in not making any changes to the
file that affected any previous code (and that never happens - yea, right).
My solution is to give 'ownership' to certain packages or files - to where
only one person (we are small, so it is person by person basis - in a large
environment, substitute 'group' for 'person') has ownership of that file.
They can feel secure that all changes to it must come through them and when
the code is 'integrated' with the other files, that only their copy of that
particular file or package will get through. This also allows others to
screw with their 'copy' of the file knowing that it won't hurt the original
because it won't come through in the integration.
If you are big enough to have testers, then you are in great shape.
However, testing a GUI is an impossible situation for 'automation'. All an
automated system can do is test mouse clicks, keyboard entries, etc. It has
no idea if what it is doing is 'intelligent' - it is just a macro engine of
some sort. So, once again, you are faced with having to have somebody (i.e.
a human) test the system because only they can figure out if the system is
running correctly or not (is the data logical/does the program 'flow'
correctly?). Don't waste your money trying to automate testing.
I've seen lots of companies promise big things with automation (Rational,
are you listening?), but you STILL have to have human thought in the builds
SOMEWHERE. Many times that automation confuses the human because they are
not sure where the bits and pieces came from and they are forced to use the
'tool' to ask each programmer what they were doing, how to correct, etc.
ACCURATE builds, in my opinion, take longer that way.
Keep in mind that we are a small programming environment, so my experience
only applies to this (3 programmers using Java). Communication between
people (or groups) is key. Save your money, work on a home-grown solution,
so you KNOW it works and you KNOW how to fix it if it doesn't work.
My 2c (okay, perhaps I have a little more than 2c).
Patrick
-----Original Message-----
From: Alan Dayley [mailto:adayley@adtron.com]
Sent: Thursday, December 28, 2000 11:49 AM
To: plug-discuss@lists.PLUG.phoenix.az.us
Subject: Version control and issue management solutions?
We are finally getting serious about automated version control and issue
management software for our engineering staff. We are discussing possible
software choices and I though someone on this list might provide some
insights.
Glossary:
-Version control: check source code or other documents (manuals,
schematics, CAD drawings) in and out of a control library system that
automatically tracks changes to the files. Build control.
-Issue management: track development projects, accept bug reports from
testing or the field, assign bugs for fixes, report progress.
Operational environment:
Currently we are a mostly M$ shop with a Linux server or two. All the
workstations are currently M$ Windows of one flavor or another. We have C
source code for the embedded systems in our products, code for (gag) DOS
and (gag gag) Win32 platforms and we will be creating Liunx based
applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux workstations very
soon. We will not be abandoning the M$ deveopment for quite some time even
as we move to a more Linux-centric base. It is a mixed target environment.
Currently 3 software engineers, 1 digital design engineer and a CAD/PCB
layout technician. Technical writers and more engineers due to be added
with growth this coming year.
As I hinted in the above, control of documents other than source code would
be very nice but the code is top priority.
What have you found to be a good solution for these needs?
CVS?
A commercial package such as PVCS or some other?
Home grown?
Any thoughts?
Alan
/------------------------------------------
|Alan Dayley www.adtron.com
|Software Engineer 602-735-0300 x331
|ADayley@adtron.com
|
|Adtron Corporation
|3710 E. University Drive, Suite 5
|Phoenix, AZ 85034
\-------------------------------------------
________________________________________________
See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post
to the list quickly and you use Netscape to write mail.
Plug-discuss mailing list - Plug-discuss@lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
--Boundary_(ID_qSSoGxYgtt1f0pmNqYHmYg)
Content-type: text/html
Content-transfer-encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Version control and issue management solutions?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>We have implemented a home-grown version for quite =
some time. See, the catch is, even if you have a piece of =
software that automatically tracks changes to files, it is not =
'intelligent' enough to know what those changes are. So, if =
things break, or if code is duplicated somehow (not an exact match, but =
more in having code duplicate function), the software cannot figure out =
which changes to keep. This must be done by an integrator (a =
human one, that is). In other words, automation cannot determine =
'intent', it can only determine 'syntax'.</FONT></P>
<P><FONT SIZE=3D2>Now, if you have more than one person working on the =
same file, the integrator is going to have great difficulty resolving =
issues within the file as well. Just because it compiles, doesn't =
mean that it works. Just because it runs with no runtime errors, =
doesn't mean that it works. Somebody has to go in there and =
figure out how it works and try to fix it when it doesn't work =
correctly (and it WILL break).</FONT></P>
<P><FONT SIZE=3D2>In addition, if you are party 'A' and you've made =
some changes to the file, and party 'B' comes along and makes changes =
to the file, when party 'A' gets the revisions, they will have to =
figure out what party 'B' did to the file unless party 'B' was =
absolutely careful in not making any changes to the file that affected =
any previous code (and that never happens - yea, right).</FONT></P>
<P><FONT SIZE=3D2>My solution is to give 'ownership' to certain =
packages or files - to where only one person (we are small, so it is =
person by person basis - in a large environment, substitute 'group' for =
'person') has ownership of that file. They can feel secure that =
all changes to it must come through them and when the code is =
'integrated' with the other files, that only their copy of that =
particular file or package will get through. This also allows =
others to screw with their 'copy' of the file knowing that it won't =
hurt the original because it won't come through in the =
integration.</FONT></P>
<P><FONT SIZE=3D2>If you are big enough to have testers, then you are =
in great shape. However, testing a GUI is an impossible situation =
for 'automation'. All an automated system can do is test mouse =
clicks, keyboard entries, etc. It has no idea if what it is doing =
is 'intelligent' - it is just a macro engine of some sort. So, =
once again, you are faced with having to have somebody (i.e. a human) =
test the system because only they can figure out if the system is =
running correctly or not (is the data logical/does the program 'flow' =
correctly?). Don't waste your money trying to automate =
testing.</FONT></P>
<P><FONT SIZE=3D2>I've seen lots of companies promise big things with =
automation (Rational, are you listening?), but you STILL have to have =
human thought in the builds SOMEWHERE. Many times that automation =
confuses the human because they are not sure where the bits and pieces =
came from and they are forced to use the 'tool' to ask each programmer =
what they were doing, how to correct, etc. ACCURATE builds, in my =
opinion, take longer that way.</FONT></P>
<P><FONT SIZE=3D2>Keep in mind that we are a small programming =
environment, so my experience only applies to this (3 programmers using =
Java). Communication between people (or groups) is key. =
Save your money, work on a home-grown solution, so you KNOW it works =
and you KNOW how to fix it if it doesn't work.</FONT></P>
<P><FONT SIZE=3D2>My 2c (okay, perhaps I have a little more than 2c).</F=
ONT>
</P>
<P><FONT SIZE=3D2>Patrick</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Alan Dayley [<A =
HREF=3D"mailto:adayley@adtron.com">mailto:adayley@adtron.com</A>]</FONT>=
<BR><FONT SIZE=3D2>Sent: Thursday, December 28, 2000 11:49 AM</FONT>
<BR><FONT SIZE=3D2>To: plug-discuss@lists.PLUG.phoenix.az.us</FONT>
<BR><FONT SIZE=3D2>Subject: Version control and issue management =
solutions?</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>We are finally getting serious about automated =
version control and issue</FONT>
<BR><FONT SIZE=3D2>management software for our engineering staff. =
We are discussing possible</FONT>
<BR><FONT SIZE=3D2>software choices and I though someone on this list =
might provide some</FONT>
<BR><FONT SIZE=3D2>insights.</FONT>
</P>
<P><FONT SIZE=3D2>Glossary:</FONT>
<BR><FONT SIZE=3D2>-Version control: check source code or other =
documents (manuals,</FONT>
<BR><FONT SIZE=3D2>schematics, CAD drawings) in and out of a control =
library system that</FONT>
<BR><FONT SIZE=3D2>automatically tracks changes to the files. =
Build control.</FONT>
<BR><FONT SIZE=3D2>-Issue management: track development projects, =
accept bug reports from</FONT>
<BR><FONT SIZE=3D2>testing or the field, assign bugs for fixes, report =
progress.</FONT>
</P>
<P><FONT SIZE=3D2>Operational environment:</FONT>
<BR><FONT SIZE=3D2>Currently we are a mostly M$ shop with a Linux =
server or two. All the</FONT>
<BR><FONT SIZE=3D2>workstations are currently M$ Windows of one flavor =
or another. We have C</FONT>
<BR><FONT SIZE=3D2>source code for the embedded systems in our =
products, code for (gag) DOS</FONT>
<BR><FONT SIZE=3D2>and (gag gag) Win32 platforms and we will be =
creating Liunx based</FONT>
<BR><FONT SIZE=3D2>applicatons (C, C++, TCL/TK, Perl, etc.) and using =
Linux workstations very</FONT>
<BR><FONT SIZE=3D2>soon. We will not be abandoning the M$ =
deveopment for quite some time even</FONT>
<BR><FONT SIZE=3D2>as we move to a more Linux-centric base. It is =
a mixed target environment.</FONT>
<BR><FONT SIZE=3D2> Currently 3 software engineers, 1 digital =
design engineer and a CAD/PCB</FONT>
<BR><FONT SIZE=3D2>layout technician. Technical writers and more =
engineers due to be added</FONT>
<BR><FONT SIZE=3D2>with growth this coming year.</FONT>
</P>
<P><FONT SIZE=3D2>As I hinted in the above, control of documents other =
than source code would</FONT>
<BR><FONT SIZE=3D2>be very nice but the code is top priority.</FONT>
</P>
<P><FONT SIZE=3D2>What have you found to be a good solution for these =
needs?</FONT>
<BR><FONT SIZE=3D2>CVS?</FONT>
<BR><FONT SIZE=3D2>A commercial package such as PVCS or some =
other?</FONT>
<BR><FONT SIZE=3D2>Home grown?</FONT>
<BR><FONT SIZE=3D2>Any thoughts?</FONT>
</P>
<P><FONT SIZE=3D2>Alan</FONT>
</P>
<P><FONT SIZE=3D2>/------------------------------------------</FONT>
<BR><FONT SIZE=3D2>|Alan =
Dayley =
www.adtron.com</FONT>
<BR><FONT SIZE=3D2>|Software =
Engineer 602-735-0300 x331</FONT>
<BR><FONT SIZE=3D2>|ADayley@adtron.com</FONT>
<BR><FONT SIZE=3D2>|</FONT>
<BR><FONT SIZE=3D2>|Adtron =
Corporation </FONT>
<BR><FONT SIZE=3D2>|3710 E. University Drive, Suite 5</FONT>
<BR><FONT SIZE=3D2>|Phoenix, AZ 85034</FONT>
<BR><FONT SIZE=3D2>\-------------------------------------------</FONT>
</P>
<BR>
<P><FONT =
SIZE=3D2>________________________________________________</FONT>
<BR><FONT SIZE=3D2>See <A =
HREF=3D"http://PLUG.phoenix.az.us/navigator-mail.shtml" =
TARGET=3D"_blank">http://PLUG.phoenix.az.us/navigator-mail.shtml</A> if =
your mail doesn't post to the list quickly and you use Netscape to =
write mail.</FONT></P>
<P><FONT SIZE=3D2>Plug-discuss mailing list - =
Plug-discuss@lists.PLUG.phoenix.az.us</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss" =
TARGET=3D"_blank">http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-=
discuss</A></FONT>
</P>
</BODY>
</HTML>=
--Boundary_(ID_qSSoGxYgtt1f0pmNqYHmYg)--