At 04:45 PM 8/2/02 -0700, Blair Zajac wrote:
>I agree branching is good for this. However, this is more with working
>with a difficult person who hasn't been in a structured development
>group. I'd like to set up more structure to review modifications before
>they go into the tree and then just have more commits to clean up the
>previous one, even if you can get them to clean it up.
This sounds like a code promotion process. Subversion will definitely need
more tools for it, but you should be able to make it work with a bit of
scripting now. I don't agree that holding open the transaction until
approval is the right idea.
David's idea of a branch per issue does solve your problem. Or you could
put each developer on their own branch and only allow merging a revision to
the trunk when an approval had been "signed" by an authorized person using
whatever method:email, property change, merge to trunk by someone with
permissions, whatever. The scary code would still be in the repository
(where it should be IMO) but it does no harm. And as an added bonus, you
can tease the person about it in the future when they finally get a clue,
because the evidence will still be there.
If you are really intent on keeping the code out of the repository, another
solution would be to remove commit access for this developer and instead
have them email patches by running "svn diff | mail -s 'log message'",
similar to how the Subversion project handles patches from non-committers.
Kind of singles the individual out if they are the only one that has to do
this, though. I guess you could get around that by writing an automated
script that called "svn ci" for all email not arriving from that particular
developer.
I guess my main comment is if the code is bad just tuck it away someplace
where it can't do any harm until it is fixed. If you don't want anyone to
ever be able to see the code again, perhaps for public relations reasons,
don't let it in the repository to begin with or restrict read access to
that branch to those wearing protective equipment. Keeping a transaction
open until you get around to reviewing a commit just doesn't feel right to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 07:16:32 2002