I am trying to work thru some issues with implementing subversion
in our development group.
First off we have a legally regulated development procedure.
We have some requirements that are simply non-negotiable and others
that could be changed with a years worth of negotiation and paperwork.
(Yes SERIOUSLY! the last change took 13 months)
Currently we are using a bug tracking system to track and assign
SCRs (System Change Requests).
We are using PVCS to "Lock" files and assign them to developers.
In general an SCR is assigned to a developer, the files are "locked"
and given to the developer and subsequently checked back into the
tree by a "gatekeeper" after manual verification she got the appropriate
files back from the developer.
Many developers have taken to "Jumping the Gun" and starting work on
code before it is checked out to them. The obvious problem is that are
changing uncontrolled code and we are seeing regression when they change
an old copy of a file and check those changes back in they are missing
changes checked back in since they got the old copy they had kicking around.
The process is cumbersome but any replacement process must still follow the
same general process.
I see the critical points as these:
1. All changes are "assigned" to a developer.
2. The code they change must be "current".
3. The code they check back in must be the code they were assigned.
#1 Can be handled by our current SCR system.
#2 I don't see any way to enforce this rule aside from adding versioned
properties or contents to all files that identify a specific file as
from a given version. This means all files are changed every time a
made to the repository. Not acceptable...IMHO.
#3 This can be enforced by making them identify a specific SCR
a given set of changes in the Commit Log Message in a format I can
the pre-commit script. This validation can be a draconian as
necessary to verify
users, privs, current SCR states etc.
What other approaches have others used to discourage or prevent
doing the Change-Old-Code-And-Check-It-Back-In-Losing-Recent-Changes-Stunt?
What are the implications of failing a commit in pre-commit script?
Does it have ANY impact on the repository?
Is there any record of failed commits stored anyplace?
I assume I can prevent SVN, tortoiseSVN and RapidSVN from trying to
merge changes and force manual intervention by setting the SVN:Mime-Type
other than TEXT/*, but... I have not been able to find any clarification
statement from the manual...
"if a file's svn:mime-type property is set to a non-text MIME type
that doesn't begin with text/, though there are exceptions)"
What are the EXCEPTIONS?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue May 25 21:11:21 2004