You might want to create an application around "svn diff | mail -s
'log'" by sending this diff to an agent which would display the changes
on a web page and provide reject/deny functionality. I imagine it would
allow an approver do download a patch, or receive it in the mail, but
from an agent and with two URLs: approve and deny. Approver likes it,
clicks approve URL, or doesn't like it, hits deny URL and has to provide
a write-up of why this wonderful piece of code was so blatantly denied,
with ready-made answers like "garbage", "doesn't work","doesn't compile
in turbo c 2.0" etc. ;-)
Blair Zajac wrote:
>Bruce Atherton wrote:
>
>
>>At 04:45 PM 8/2/02 -0700, Blair Zajac wrote:
>>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.
>>
>>
>
>We need a real diff format that could be read in to handle moves, property
>changes, etc. Like what Tom Lord has been proposing to work on.
>
>Emailing diffs is what I do now and it gets to be a pain. A nice automated
>web page showing the proposed diff and having an accept or reject button
>would sure be nice. This is similar to the Mailman interface to accepting
>posts from non-members.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 18:46:02 2002