I'm looking to either use or write a tool that would allow us to achieve the following workflow with our CVS repository:
- Developers write code and commit changes - Lead developer reviews the code changes, and either signs off on it or sends it back to the developer with comments - When lead developer signs off on it, code is moved/merged into a 'clean' repository from which clean builds/dists can be produced, testing suites run against, etc... I searched for the better part of a day and haven't found anything that really performs this "merge management / source tree protection" role. I've found a few tools (Bonsai, codestriker) that allow for easy review of changes that have been made and allow for commenting on them but nothing that keeps developer commits from tainting a tree until approved. I've schemed up a fairly simple tool in my head that I could write that would fulfill my goals, but I wanted to see if you could shoot any holes in it, or tell me of other tools I may have missed. For a first pass I was thinking of: - making a devel branch and a main branch. - all developers work off of devel branch at all times. - i write a perl web tool with a db backend that tracks the last revision of each file that was approved by the lead developer and also can query cvs and find out the current revision - perl web tool will be able to show lead developer all the changes that have yet to be approved that are on the devel branch - lead developer can pull up diffs (I'll use ViewCVS or cvsweb for this functionality) and review the changes - lead developer can send comments back to the code author (maybe via bugzilla?) - lead developer can approve a change - approval of a change leads to a merge of that file back onto the main trunk and tagging of that file on devel (so we'll know how far back to look the next time we need to merge this file) Does such a (free) tool like this exist for cvs? It would seem to be a common wish but I looked around at how some of these big projects manage this. Mozilla, for example, once you have commit privileges you can commit right to the tree, you are -supposed- to get approval from a supervisor and run a test suite first and check Bonsai to see if the tree is open, etc... but they don't seem to have any mechanism to actually enforce this - i.e. a harried or irresponsible developer can commit to the main tree from which builds are produced without approval and without running appropriate tests and nothing would stop him. I would like to know what the weaknesses are in my plan. I already see one - that is that one developer could break the branch and prevent another developer from continuing work. To thwart that I'd need to give each developer his own branch and the developers would have to do an update from the HEAD every now and then to benefit from the other developers' work. For the number of developers we have right now (3) that might be overkill, and the main problem we're trying to combat is not developers stopping each other from working, but developers tainting the tree from which we produce distributions for internal testing and such. However, maybe in the future each developer would need his own branch. Another weakness is that I'll seemingly have to do the merging one file at a time back onto the trunk and track a lot of different tags, not too big of a deal right now, we have maybe 100 files total, but still inefficient. So, what are the other holes in this approach and what work has already been done in this arena? Thanks, Fran _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
