Commit hooks and control of bad development practices?

[m christensen <df...@xmission.com>]

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.

Proposed approach:
#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 
being
   from a given version. This means all files are changed every time a 
commit is
   made to the repository. Not acceptable...IMHO.

#3 This can be enforced by making them identify a specific SCR 
associated with
   a given set of changes in the Commit Log Message in a format I can 
parse within
   the pre-commit script. This validation can be a draconian as 
necessary to verify
   users, privs, current SCR states etc.



Questions:
What other approaches have others used to discourage or prevent 
developers from
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 
automagically
merge changes and force manual intervention by setting the SVN:Mime-Type 
to something
other than TEXT/*, but... I have not been able to find any clarification 
of this
statement from the manual...
"if a file's svn:mime-type property is set to a non-text MIME type 
(generally, something
that doesn't begin with text/, though there are exceptions)"

What are the EXCEPTIONS?


Marc




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Commit hooks and control of bad development practices?

[m christensen <df...@xmission.com>]

Dale Hagglund wrote:

>You may want to consider the following model.
>
>1. The product trunk is owned by the release engineering team.  Only
>   they can commit to the trunk.
>---------SNIP-----------
>  
>
Good idea, 2 issues here are the fact much of the 'code' is a binary 
format generated by GUI Tools
and impossible to 'merge' meaning merges will mean reimplementation of 
one of the 2 variants over
the top of the other.
This means we tend to keep the branches very short time-wise.
Branches in general have a VERY bad reputation here, that is an issue we 
would need to address as well.

Thanks for the ideas.

Marc


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Commit hooks and control of bad development practices?

[Dale Hagglund <rd...@yottayotta.com>]

You may want to consider the following model.

1. The product trunk is owned by the release engineering team.  Only
   they can commit to the trunk.

2. When an SCR, a branch (say /branches/scrNNNN) is created, based on
   the the current head of the trunk.  The SCR is owned by the
   developer assigned to the SCR.  Only the developer for the SCR can
   commit to this branch.

3. The developer makes his changes to resolve the SCR, on the
   appropriate branch.  When the fix is complete, he notifies the
   release engineering team.

4. The releng team decides on the order in which pending SCRs are
   integrated into the trunk.  Doing so does require merges, but they
   occur only when the releng wants them to do so.  If merge conflicts
   arise, the releng team pulls in the appropriate developers to
   resolve the conflicts.

The exclusive ownership of branches implied by the scheme above
becomes easier if sufficiently capable locks implemented, but I
believe svn could support that model today with commit hooks.

Does this map well onto the process you want?  Note that developers no
longer own files but branches.  Potential concurrent file changes are
still resolved formally, but now at a slightly later time.

Dale Hagglund.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org