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

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