Re: mechanisms for reviews needed

[Jacob]

Pierre Asselin 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 could use the term "added to" the repository, but as "add"
also has a technical meaning in CVS that would be wrong too?
I am very familiar with the tool, thank you, and I am sure
everyone understood what I meant.

> > 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 !

Yes it has to go somewhere. My question is if it is possible to
put it in ("comit" it to) a _temporar_ location until explicitly
accepted by the reviewers.

A sequence ("use case") could be something like this:

  joe> cvs commit
  joe> -- CVS: Changes submitted. Revision is #33508

At this point an email is sent to all reviewers stating
that revision #33508 is awaiting a review.

Reviewer Jim, (optionally) fetch the changes, review the code and
accept/rejects the revision:

  jim> cvs update 33508
  jim> cvs accept 33508

At this point the code is commited to the repository, and an
email is sent to all participants to acknowledge this fact.
If is was rejected joe would be notified about the fact and
forced to redo it according to suggestions of the reviewer.

> 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.

The main problem is that each developer is the sole responsible
for the quality of the work commited. This may work well in a
small organization, or if the rules are strict and everyone
extremely diciplined. In general this want be true.

CVS branching could be used, but that would be a hack. I'd want
this as an integrated service in the VCS, but I see that your
answer to my question is "no".

So let me restate it: Is there any plans for adding such a feature
in CVS or Subversion?

Thanks!