--=====================_16683217==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Excellent discussion! I was hoping that there already is an "all in one" solution that was good enough to use for all these things you are talking about. The only company I see that at least claims to cover it all is the PVCS series of packages from Merant. The biggest problem there is it's requirements for M$ servers. The quick answer seems to be that there are no quick answers. Well, let me get specific then: Has anyone used a combination of CVS and Bugzilla? Those two pieces would give us version management and bug tracking and the source is available. Alan At 09:10 PM 12/30/00 -0700, you wrote: >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 ----- >From: Patrick Rhodes >To: >'plug-discuss@lists.PLUG.phoenix.az.us' > >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). > >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 > --=====================_16683217==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Excellent discussion!

I was hoping that there already is an "all in one" solution that was good enough to use for all these things you are talking about.  The only company I see that at least claims to cover it all is the PVCS series of packages from Merant.  The biggest problem there is it's requirements for M$ servers.

The quick answer seems to be that there are no quick answers.  Well, let me get specific then:  Has anyone used a combination of CVS and Bugzilla?  Those two pieces would give us version management and bug tracking and the source is available.

Alan

At 09:10 PM 12/30/00 -0700, you wrote:
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 proces= s 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).

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           &nb= sp; 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=20
--=====================_16683217==_.ALT--