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.
> 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.
Unfortunately, that's not an option.
> Keeping a transaction open until you get around to reviewing a commit just
> doesn't feel right to me.
Having an XML or standardized diffs for review would work though.
That would be cool. Send the diff to an email address, it gets queued up
for review. A reviewer says ok, then a process tries to commit it. It may
conflict, but it wouldn't hurt the repository if it does.
Best,
Blair
--
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
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:24:18 2002