[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: mechanisms for reviews needed
RE: mechanisms for reviews needed
Mon, 1 Aug 2005 09:24:08 +1000
This is certainly something we are interested in with CVSNT.
CVSNT is free/GPL (just like CVS) and runs on Linux/Windows/Unix/Mac.
We've done a lot of work in the last year adapting branches for multiple
purposes, basically the original purpose and also as "promotion levels".
We have also added change sets/defect tracking integration so that a
developer can mark work as "bug 1234".
Cvs edit -b 1234 hello.c hello.h
Cvs edit -b 1235 xxxx.c xxxx.h
Cvs commit -b 1234 -m "this only commits changes for bug 1234"
I would have proposed that you allow the developer to commit to the
trunk and this triggers the review process (we have an e-mail trigger
for this purpose). The reviewer using a sandbox for the promotion level
TEST, does a merge:
cvs update -e 2101 -B 1234 -j 1
This merges in the changes for bug 1234 and creates a new bug 2101 (you
could use the same bug number, but some organisations want a new job
number for moving something to test).
The bug numbers can be easily tied into a defect tracking system such as
The person reviews the fix (or reviews the fix using CVSWEB and then
does the merge). If all is OK the reviewer then commits the merge to
TEST. So Trunk is a "unreviewed area" and TEST is a "reviewed area".
CVSNT has what are called "mergepoints" which tracks when changes are
merged and the origins of the merge so you can visually "see" where the
merges occurred using things like cvsgraph.
I would have proposed all this but you said that you didn't want to use
Is the procedure I suggested workable for you? If not what would be
your reasons for avoiding it... I certainly don't think we've got this
perfect at CVSNT yet, but since you are asking for such a feature I
though I could use it as an opportunity to learn a little about someone
elses success/fail criteria.
I tried to send this to you directly rather than the CVS list, however
it appears your e-mail address is bogus... Please contact me off the
list if you would like to discuss this feature in CVSNT further.
The CVSNT newsgroup is here:
Behalf Of Jacob
Sent: Saturday, 30 July 2005 7:23 PM
Subject: Re: mechanisms for reviews needed
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
>>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.
> 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
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?