Version control and issue management solutions?

Attachments:
Message as email (text/plain)

Author: Patrick Rhodes
Date:
Subject: Version control and issue management solutions?

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>

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).</F=
ONT>


Patrick


-----Original Message-----
 From: Alan Dayley [<A =
HREF=3D"mailto:adayley@adtron.com">mailto:adayley@adtron.com</A>]=

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

Plug-discuss mailing list  -  =
Plug-discuss@lists.PLUG.phoenix.az.us
 <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>


</BODY>
</HTML>=

--Boundary_(ID_qSSoGxYgtt1f0pmNqYHmYg)--

This message is part of the following thread:
	the complete thread tree sorted by date
	AlanDayleyadayley@adtron.com at
	PatrickRhodesPatrick.Rhodes@asu.edu at