<snip>
> We have talked about using this mechanism to have a "nightly
> build" and
> "weekly tested" tag scheme going, which will allow developers
> to have a
> stable version to link to when working on their components.
>
Therein generally lies the crutch of the problem - if a project is large
enough and everybody has direct access to the version control system then
there are generally enough individuals who end up stuffing it up for the
rest of the developers - either through simple mistakes or sheer
incompetence :-)
I have worked on a 40+ engineer project that used PVCS in exactly this
manner - everybody had the right and privilege of checking in their work
when they deemed that it was complete and working (we originally tried to
use PVCS privileges - but the teamleaders where so overworked that they gave
out their passwords to team members - thus nulifying the attempt :-)).
The net result was that approximately 30 - 50% of the time the developers
were faced with no stable base to compile their work against i.e. incorrect,
incomplete and "broken" files were checked in and the overnight rebuild of
the baseline which everybody compiled and linked against was found to be
broken the next morning. This would take anywhere from a 1/2hr to all day to
find and correct the problem. In the meantime everybody else spun their
wheels :-)
The solution we used at that time and for that project was to insert a
simple layer of tools/scripts between the developers and the repository that
managed who had what files booked out and against what Change Request - an
intern spent 3 weeks writing them :-) This meant that direct access to the
PVCS repository could be and was removed completely from the developers
grasp.
We then put a build engineer in place and all commits went to that
individual with the relevant test instructions etc The build engineer had
tools that moved the changes from the developers area into an intermediate
"build" area - where everything was recompiled and tested - any particular
change that didn't compile or failed testing was extracted from the list of
candidates and returned to the developer for "further work". Only when all
the remainder had been proven were those changes moved into the base
repository - the "stable" area that all developers compiled and built
against.
I had one individual from an SCM tool company once describe it as a "Mother,
may I?" system - very aptly described :-) But after the initial teething
problems (and the wailing and gnashing of teeth from individuals who
resented the lose of "freedom") the system was voted to be extremely
successful and some of the strongest supporters afterwards were the very
people who complained longest and hardest as it was being developed :-)
We did consider using labels in PVCS as a possible work-around - but it was
decided that there was still general problems which were difficult or
impossible to overcome when so many people had direct access to the
repository i.e. with a project that large it was necessary at times to know
what files were changed as a result of what CR - and individuals generally
found it impossible to remember to mark the comments with the CR # when they
checked it in :-) I could go on and on about the pros and cons of this
system - suffice to say that it stood the test of time of producing stable
builds that went to a customer for acceptance testing for over 3 years
without any problems - in fact, it raised the customers confidence
enormously :-). It was a "commercial" project being done to mil-spec
standards (2167A) so full configuration management practices were
implemented and followed i.e. Change Control Boards, CRs being investigated,
solutions proposed, approval (or otherwise) before work was allowed to
proceed and then verification that the work done met the original problem
etc.
Of course when you are working a much smaller project none of this is
required - but on "large" projects I consider such mechanisms to be
mandatory - otherwise you waste far and away too much time that could have
been better spent getting the product out the door :-)
Peter
Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.
This communication is confidential and may contain legally privileged information.
By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal
privilege in,the content of the email and of any attachments.
If the recipient of this message is not the intended addressee, please call ResMed immediately on +61 2 9886 5000 Sydney, Australia.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 00:19:25 2004