Version control and issue management solutions?
David Demland
demland@home.com
Sat, 30 Dec 2000 21:10:16 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_0020_01C072A4.E85A2A00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
RE: Version control and issue management solutions?Not to cause =
confusion over what is being talked about here, but there is one basic =
problem that has been over looked at this point. There is no possible =
way that SCM, Software Configuration Management, can be done by hand and =
done right. The tools that were originally asked about all added up to =
SCM. SCM is a combination of development and processes for development. =
Yet the answer given is the most common mistake done in development =
today. That mistake is to confuse source control with SCM. The questions =
not answered yet are ones like:
* How do I get different versions of the information I am looking for? =
(It is not important about what kind of information that is)
* How will I identify what information the customer has? (Files or data =
can be included in this and this depends on the format of shipped data)
* Is all the data going to be completed at one point in time? (Can I =
label all the files at once like a shipment of a product)
* Will there be more that one concurrent path for the information to be =
on at one time? (More that one version of development at a time)
* How will defects be tracked? (These are not part of source control)
* How will defects be fixed? (What is the process for fixing and =
verifying that the fix has no side effects)
* How are the SCIs, Software Configuration Items, track? (What =
components interact with other components)
* How do I control what is built? (What process will ensure that the =
correct files and data are being used)
As I see it the answer to the original questions is: you need source =
control software, defect tracking software, and build software (system). =
There is no one product that can do all of these. You will have to =
identify what areas of trade off exist and what trade offs can be made. =
After this you can look at the different tools to see what you can use. =
I have spent a lot of time working on answering these types of questions =
for us at work and it is very hard to know what is the best way to go at =
times. For example CVS will fail to handle some of the above questions =
at all. Some of the questions CVS handles poorly for some environments. =
These are the types of trade offs you must decide to make. These will =
also differ from one place to another. Take note - Rational, Starbase, =
Microsoft, GNU, and many other players are trying to fit in somewhere in =
this whole picture. The reality is that no one player will have the =
whole answer. You have to understand what you are trying to do, who =
supplies the best answer to each piece, and how all the pieces fit that =
complete the correct picture for you. In other words do not buy in that =
any one company can give the total answer. Study, study, and study some =
more before you make a decision. Remember making the wrong decision at =
this point will come back to haunt you latter. Trust me I am reworking a =
system that we have done wrong for the last three years because no one =
took the time to ask the right questions before they decided to go down =
a path. Now we can not handle the production process properly. Remember =
that if the production process fails the product will fail.
Hope this is some help.
Thank You,
David Demland
demland@home.com
----- Original Message -----=20
From: Patrick Rhodes=20
To: 'plug-discuss@lists.PLUG.phoenix.az.us'=20
Sent: Thursday, December 28, 2000 12:11 PM
Subject: RE: Version control and issue management solutions?
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).=20
Patrick=20
-----Original Message-----=20
From: Alan Dayley [mailto:adayley@adtron.com]=20
Sent: Thursday, December 28, 2000 11:49 AM=20
To: plug-discuss@lists.PLUG.phoenix.az.us=20
Subject: Version control and issue management solutions?=20
We are finally getting serious about automated version control and =
issue=20
management software for our engineering staff. We are discussing =
possible=20
software choices and I though someone on this list might provide some=20
insights.=20
Glossary:=20
-Version control: check source code or other documents (manuals,=20
schematics, CAD drawings) in and out of a control library system that=20
automatically tracks changes to the files. Build control.=20
-Issue management: track development projects, accept bug reports from =
testing or the field, assign bugs for fixes, report progress.=20
Operational environment:=20
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=20
source code for the embedded systems in our products, code for (gag) =
DOS=20
and (gag gag) Win32 platforms and we will be creating Liunx based=20
applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux workstations =
very=20
soon. We will not be abandoning the M$ deveopment for quite some time =
even=20
as we move to a more Linux-centric base. It is a mixed target =
environment.=20
Currently 3 software engineers, 1 digital design engineer and a =
CAD/PCB=20
layout technician. Technical writers and more engineers due to be =
added=20
with growth this coming year.=20
As I hinted in the above, control of documents other than source code =
would=20
be very nice but the code is top priority.=20
What have you found to be a good solution for these needs?=20
CVS?=20
A commercial package such as PVCS or some other?=20
Home grown?=20
Any thoughts?=20
Alan=20
/------------------------------------------=20
|Alan Dayley www.adtron.com=20
|Software Engineer 602-735-0300 x331=20
|ADayley@adtron.com=20
|=20
|Adtron Corporation =20
|3710 E. University Drive, Suite 5=20
|Phoenix, AZ 85034=20
\-------------------------------------------=20
________________________________________________=20
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=20
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss=20
------=_NextPart_000_0020_01C072A4.E85A2A00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Version control and issue management =
solutions?</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Not to cause confusion over what is =
being talked=20
about here, but there is one basic problem that has been over looked at =
this=20
point. There is no possible way that SCM, Software Configuration =
Management, can=20
be done by hand and done right. The tools that were originally asked =
about all=20
added up to SCM. SCM is a combination of development and processes for=20
development. Yet the answer given is the most common mistake done in =
development=20
today. That mistake is to confuse source control with SCM. The questions =
not=20
answered yet are ones like:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>* How do I get different versions =
of the=20
information I am looking for? (It is not important about what kind of=20
information that is)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* How will I identify what information =
the customer=20
has? (Files or data can be included in this and this depends on the =
format of=20
shipped data)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* Is all the data going to be completed =
at one=20
point in time? (Can I label all the files at once like a shipment of a=20
product)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* Will there be more that one =
concurrent path for=20
the information to be on at one time? (More that one version of =
development at a=20
time)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* How will defects be tracked? (These =
are not part=20
of source control)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* How will defects be fixed? (What is =
the process=20
for fixing and verifying that the fix has no side effects)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* How are the SCIs, Software =
Configuration Items,=20
track? (What components interact with other components)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>* How do I control what is built? (What =
process=20
will ensure that the correct files and data are being used)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As I see it the answer to the original =
questions=20
is: you need source control software, defect tracking software, and =
build=20
software (system). There is no one product that can do all of these. You =
will=20
have to identify what areas of trade off exist and what trade offs can =
be made.=20
After this you can look at the different tools to see what you can use. =
I have=20
spent a lot of time working on answering these types of questions for us =
at work=20
and it is very hard to know what is the best way to go at times. For =
example CVS=20
will fail to handle some of the above questions at all. Some of the =
questions=20
CVS handles poorly for some environments. These are the types of trade =
offs you=20
must decide to make. These will also differ from one place to another. =
Take note=20
- Rational, Starbase, Microsoft, GNU, and many other players are =
trying to=20
fit in somewhere in this whole picture. The reality is that no one =
player will=20
have the whole answer. You have to understand what you are trying to do, =
who=20
supplies the best answer to each piece, and how all the pieces =
fit that=20
complete the correct picture for you. In other words do not buy in that =
any one=20
company can give the total answer. Study, study, and study some more =
before you=20
make a decision. Remember making the wrong decision at this point will =
come back=20
to haunt you latter. Trust me I am reworking a system that we have done =
wrong=20
for the last three years because no one took the time to ask the right =
questions=20
before they decided to go down a path. Now we can not handle =
the production=20
process properly. Remember that if the production process fails the =
product will=20
fail.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Hope this is some help.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thank You,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>David Demland</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:demland@home.com">demland@home.com</A></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3DPatrick.Rhodes@asu.edu =
href=3D"mailto:Patrick.Rhodes@asu.edu">Patrick=20
Rhodes</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
title=3Dplug-discuss@lists.PLUG.phoenix.az.us=20
=
href=3D"mailto:'plug-discuss@lists.PLUG.phoenix.az.us'">'plug-discuss@lis=
ts.PLUG.phoenix.az.us'</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, December 28, =
2000 12:11=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Version control =
and issue=20
management solutions?</DIV>
<DIV><BR></DIV>
<P><FONT size=3D2>We have implemented a home-grown version for quite =
some=20
time. See, the catch is, even if you have a piece of software =
that=20
automatically tracks changes to files, it is not 'intelligent' enough =
to know=20
what those changes are. So, if things break, or if code is =
duplicated=20
somehow (not an exact match, but more in having code duplicate =
function), the=20
software cannot figure out which changes to keep. This must be =
done by=20
an integrator (a human one, that is). In other words, automation =
cannot=20
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=20
file, the integrator is going to have great difficulty resolving =
issues within=20
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=20
works. Somebody has to go in there and figure out how it works =
and try=20
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=20
to the file, and party 'B' comes along and makes changes to the file, =
when=20
party 'A' gets the revisions, they will have to figure out what party =
'B' did=20
to the file unless party 'B' was absolutely careful in not making any =
changes=20
to the file that affected any previous code (and that never happens - =
yea,=20
right).</FONT></P>
<P><FONT size=3D2>My solution is to give 'ownership' to certain =
packages or=20
files - to where only one person (we are small, so it is person by =
person=20
basis - in a large environment, substitute 'group' for 'person') has =
ownership=20
of that file. They can feel secure that all changes to it must =
come=20
through them and when the code is 'integrated' with the other files, =
that only=20
their copy of that particular file or package will get through. =
This=20
also allows others to screw with their 'copy' of the file knowing that =
it=20
won't hurt the original because it won't come through in the=20
integration.</FONT></P>
<P><FONT size=3D2>If you are big enough to have testers, then you are =
in great=20
shape. However, testing a GUI is an impossible situation for=20
'automation'. All an automated system can do is test mouse =
clicks,=20
keyboard entries, etc. It has no idea if what it is doing is=20
'intelligent' - it is just a macro engine of some sort. So, once =
again,=20
you are faced with having to have somebody (i.e. a human) test the =
system=20
because only they can figure out if the system is running correctly or =
not (is=20
the data logical/does the program 'flow' correctly?). Don't =
waste your=20
money trying to automate testing.</FONT></P>
<P><FONT size=3D2>I've seen lots of companies promise big things with =
automation=20
(Rational, are you listening?), but you STILL have to have human =
thought in=20
the builds SOMEWHERE. Many times that automation confuses the =
human=20
because they are not sure where the bits and pieces came from and they =
are=20
forced to use the 'tool' to ask each programmer what they were doing, =
how to=20
correct, etc. ACCURATE builds, in my opinion, take longer that=20
way.</FONT></P>
<P><FONT size=3D2>Keep in mind that we are a small programming =
environment, so=20
my experience only applies to this (3 programmers using Java). =20
Communication between people (or groups) is key. Save your =
money, work=20
on a home-grown solution, so you KNOW it works and you KNOW how to fix =
it if=20
it doesn't work.</FONT></P>
<P><FONT size=3D2>My 2c (okay, perhaps I have a little more than =
2c).</FONT>=20
</P>
<P><FONT size=3D2>Patrick</FONT> </P>
<P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Alan=20
Dayley [<A=20
=
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=20
size=3D2>To: plug-discuss@lists.PLUG.phoenix.az.us</FONT> <BR><FONT=20
size=3D2>Subject: Version control and issue management =
solutions?</FONT>=20
</P><BR><BR>
<P><FONT size=3D2>We are finally getting serious about automated =
version control=20
and issue</FONT> <BR><FONT size=3D2>management software for our =
engineering=20
staff. We are discussing possible</FONT> <BR><FONT =
size=3D2>software=20
choices and I though someone on this list might provide some</FONT> =
<BR><FONT=20
size=3D2>insights.</FONT> </P>
<P><FONT size=3D2>Glossary:</FONT> <BR><FONT size=3D2>-Version =
control: check=20
source code or other documents (manuals,</FONT> <BR><FONT =
size=3D2>schematics,=20
CAD drawings) in and out of a control library system that</FONT> =
<BR><FONT=20
size=3D2>automatically tracks changes to the files. Build =
control.</FONT>=20
<BR><FONT size=3D2>-Issue management: track development projects, =
accept bug=20
reports from</FONT> <BR><FONT size=3D2>testing or the field, assign =
bugs for=20
fixes, report progress.</FONT> </P>
<P><FONT size=3D2>Operational environment:</FONT> <BR><FONT =
size=3D2>Currently we=20
are a mostly M$ shop with a Linux server or two. All the</FONT>=20
<BR><FONT size=3D2>workstations are currently M$ Windows of one flavor =
or=20
another. We have C</FONT> <BR><FONT size=3D2>source code for the =
embedded=20
systems in our products, code for (gag) DOS</FONT> <BR><FONT =
size=3D2>and (gag=20
gag) Win32 platforms and we will be creating Liunx based</FONT> =
<BR><FONT=20
size=3D2>applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux =
workstations=20
very</FONT> <BR><FONT size=3D2>soon. We will not be abandoning =
the M$=20
deveopment for quite some time even</FONT> <BR><FONT size=3D2>as we =
move to a=20
more Linux-centric base. It is a mixed target =
environment.</FONT>=20
<BR><FONT size=3D2> Currently 3 software engineers, 1 digital =
design=20
engineer and a CAD/PCB</FONT> <BR><FONT size=3D2>layout =
technician. =20
Technical writers and more engineers due to be added</FONT> <BR><FONT=20
size=3D2>with growth this coming year.</FONT> </P>
<P><FONT size=3D2>As I hinted in the above, control of documents other =
than=20
source code would</FONT> <BR><FONT size=3D2>be very nice but the code =
is top=20
priority.</FONT> </P>
<P><FONT size=3D2>What have you found to be a good solution for these=20
needs?</FONT> <BR><FONT size=3D2>CVS?</FONT> <BR><FONT size=3D2>A =
commercial=20
package such as PVCS or some other?</FONT> <BR><FONT size=3D2>Home =
grown?</FONT>=20
<BR><FONT size=3D2>Any thoughts?</FONT> </P>
<P><FONT size=3D2>Alan</FONT> </P>
<P><FONT size=3D2>/------------------------------------------</FONT> =
<BR><FONT=20
size=3D2>|Alan=20
=
Dayley &=
nbsp;=20
www.adtron.com</FONT> <BR><FONT size=3D2>|Software=20
Engineer 602-735-0300 x331</FONT>=20
<BR><FONT size=3D2>|ADayley@adtron.com</FONT> <BR><FONT =
size=3D2>|</FONT>=20
<BR><FONT size=3D2>|Adtron=20
Corporation =
</FONT><BR><FONT=20
size=3D2>|3710 E. University Drive, Suite 5</FONT> <BR><FONT =
size=3D2>|Phoenix,=20
AZ 85034</FONT> <BR><FONT=20
size=3D2>\-------------------------------------------</FONT> </P><BR>
<P><FONT =
size=3D2>________________________________________________</FONT>=20
<BR><FONT size=3D2>See <A target=3D_blank=20
=
href=3D"http://PLUG.phoenix.az.us/navigator-mail.shtml">http://PLUG.phoen=
ix.az.us/navigator-mail.shtml</A>=20
if your mail doesn't post to the list quickly and you use Netscape to =
write=20
mail.</FONT></P>
<P><FONT size=3D2>Plug-discuss mailing list - =20
Plug-discuss@lists.PLUG.phoenix.az.us</FONT> <BR><FONT size=3D2><A =
target=3D_blank=20
=
href=3D"http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss">ht=
tp://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss</A></FONT>=20
</P></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0020_01C072A4.E85A2A00--