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.
Truly, this isn't a SCM issue but a management issue. It's just that
management is harder than throwing technology at it :)
Best,
Blair
David Waite wrote:
>
> 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
--
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 01:45:44 2002