Re: mechanisms for reviews needed

[Pierre Asselin]

Jacob <address@hidden> wrote:
> What mechanisms are available for handling _reviews_
> before changes are merged to the repository?

Changes aren't "merged" in the repository.  Your
terminology suggests unfamiliarity with the tool.
In CVS, "merge" has a technical meaning that doesn't
fit your use of the word.


> I'd like a system where dedicated group members
> are notified per e-mail on a commit, and the code is
> put into the repository only after it has been
> explicitly accepted by (one of) them.

The email after every commit is easy enough, you can use the loginfo
hook to run an arbitrary command after each commit.  That command
can send an email to the reviewers if you like.
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC175

The rest of your question makes no sense, because to commit *is*
to put the new code in the repository.  It has to go somewhere !


> Is this possible?

In a way.  You could do all your development on branches and
allow only an integrator to merge (CVS jargon) the work to
the trunk after the branch work has been accepted by reviewers.
In this model, the trunk holds the stable code.

In my experience, CVS is easier to use in an informal way, where
the trunk contains *unstable* code.  Frequent commits are the
primary means of communication between developers.  When all
milestones are met, the trunk is tagged and a release branch is
started.  The branch is used only to stabilize and debug the code.

If you need a more formal process you may want to try a
different revision control system.  There are others.  From
memory, Aegis tends to come up in this type of discussions.
http://aegis.sourceforge.net/


-- 
pa at panix dot com