I could see this working via branching - the developers do not have
commit access to the release branches, but can create new branches
corresponding to known issues, and has a mechanism for signalling for
review after the change has been made and tested (possibly after several
commits).
The person in charge of merging approved changes would probably need
something more complex than a CGI, however - I would hope that the merge
would then be tested before being commited to the release branch.
-David Waite
Blair Zajac wrote:
>At my work, we have a review-commit model. I'd like to try something
>like this that uses Subversion's txn support.
>
>1) Developer does work.
>2) Developer commits.
>3) Commit system notes that developer's commit needs review and
> a) Keeps the txn in the database and quits.
> b) Runs a modified commit-email.pl on the txn to send out a review
> request.
> c) Quits without deleting txn.
>4) Somebody reviews the changes and say OKs it.
>5) The manager goes to a CGI interface to the repos which lists all
> the outstanding txn's and selects the txn to apply.
>
>This is nice because then you know the exact commit being applied to
>the tree. Normally in CVS you do the review and the developer may have
>made some more changes to the modification that were not reviewed and
>checks that in.
>
>Is this possible? Would it work in this case?
>
>1) Developer 1's commit gets saved for review and later commit.
>2) Developer 2 has special access and commits immediately.
>
>I'm guessing that invalidates 1's txn?
>
>Also, do the txn's store the time that they were created in
>server time so they can be properly sorted? You don't want
>client time, because that may be messed up.
>
>Best,
>Blair
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 01:37:32 2002