Re: Commit hooks and control of bad development practices?

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
Received on Wed May 26 02:51:32 2004