[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Commit hooks and control of bad development practices?

From: m christensen <dfs_at_xmission.com>
Date: 2004-05-25 21:09:33 CEST

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
Received on Tue May 25 21:11:21 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.