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 RE: Version control and issue management = solutions?
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:
 
* 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)
* 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)
* 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)
* 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)
* How will defects be tracked? (These = are not part=20 of source control)
* How will defects be fixed? (What is = the process=20 for fixing and verifying that the fix has no side effects)
* How are the SCIs, Software = Configuration Items,=20 track? (What components interact with other components)
* How do I control what is built? (What = process=20 will ensure that the correct files and data are being used)
 
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.
 
Hope this is some help.
 
Thank You,
 
David Demland
demland@home.com
----- Original Message -----
From:=20 Patrick=20 Rhodes
To: 'plug-discuss@lis= ts.PLUG.phoenix.az.us'=20
Sent: Thursday, December 28, = 2000 12:11=20 PM
Subject: RE: Version control = and issue=20 management solutions?

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

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

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

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.

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.

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.

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.

My 2c (okay, perhaps I have a little more than = 2c).=20

Patrick

-----Original Message-----
From: Alan=20 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?=20



We are finally getting serious about automated = version control=20 and issue
management software for our = engineering=20 staff.  We are discussing possible
software=20 choices and I though someone on this list might provide some =
insights.

Glossary:
-Version = control: check=20 source code or other documents (manuals,
schematics,=20 CAD drawings) in and out of a control library system that =
automatically tracks changes to the files.  Build = control.=20
-Issue management: track development projects, = accept bug=20 reports from
testing or the field, assign = bugs for=20 fixes, report progress.

Operational environment:
Currently we=20 are a mostly M$ shop with a Linux server or two.  All the=20
workstations are currently M$ Windows of one flavor = or=20 another.  We have C
source code for the = embedded=20 systems in our products, code for (gag) DOS
and (gag=20 gag) Win32 platforms and we will be creating Liunx based =
applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux = workstations=20 very
soon.  We will not be abandoning = the M$=20 deveopment for quite some time even
as we = move to a=20 more Linux-centric base.  It is a mixed target = environment.=20
 Currently 3 software engineers, 1 digital = design=20 engineer and a CAD/PCB
layout = technician. =20 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=20 source code would
be very nice but the code = is top=20 priority.

What have you found to be a good solution for these=20 needs?
CVS?
A = commercial=20 package such as PVCS or some other?
Home = grown?=20
Any thoughts?

Alan

/------------------------------------------ =
|Alan=20 = Dayley           &= nbsp;=20 www.adtron.com
|Software=20 Engineer       602-735-0300 x331=20
|ADayley@adtron.com
|=20
|Adtron=20 Corporation         =
|3710 E. University Drive, Suite 5
|Phoenix,=20 AZ  85034
\-------------------------------------------


________________________________________________=20
See http://PLUG.phoen= ix.az.us/navigator-mail.shtml=20 if your mail doesn't post to the list quickly and you use Netscape to = write=20 mail.

Plug-discuss mailing list  - =20 Plug-discuss@lists.PLUG.phoenix.az.us
ht= tp://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss=20

------=_NextPart_000_0020_01C072A4.E85A2A00--