Jacob, 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". Ie: 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 Bugzilla. 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 branches.... 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: http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt or news://news.cvsnt.org/support.cvsnt Regards, Arthur Barrett -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacob Sent: Saturday, 30 July 2005 7:23 PM To: [email protected] 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 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! _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
