Hi Laurent. I think you are on the right track. Here's how we used CVS in my last work environment which worked great - IMHO.
One central CVS server. Everytime our CM person performed a successful build the project's files would be tagged with that builds ID. This way we could always reproduce the build at any point in the future. When we were approaching the end of a projects cycle and the code was pretty much stable we would branch the project and label the branch with the release version number. As bugs were reported back on that release, the bugs would be fixed on the branch code. Meanwhile work on the next release would continue and applied to the trunk (main line) code. Any bug fixes that were applied to the branch code would get merged into the main line if it made sense to do so. When you say "each developer would get a version..." I assume you mean that each developer has their own version of the project. This is how we did it. Each developer had their own copy of the code (the whole project). Developers would update their copy regularly to have the most up to date code on their machines. This way any changes made would most likely work with the rest of the project. When a developer is ready to check in changes, they would first update their code to make sure that they had the most recent codebase, re-compile to ensure their changes wouldn't break the build, re-run the unit test suite to make sure they hadn't broken any functionality then commit their changes. The best way to do this is to check in frequently. That way when you do have conflicts they are small and can be easily fixed. CVS in general handles merges very well. It's only when two people modify the same lines in the same file that you get conflicts happening. This happens very, very rarely. The process can be completely painless if you check in frequently, and don't wait for extended periods of time before checking in. You always want to be working with the latest source code in the repository. We were also using Tomcat as our server and yes each developer had a copy of it. This worked very well. For one reason it isolated your testing environment. Because you were working on your own machine with your own copy of Tomcat, when an exception occurred or something unexpected happened you knew that it was due to something you did, and wasn't the result of some external action. To make sure that each developer had the same setup we checked our modified version of Tomcat into CVS as well. That way all that a developer had to do to set up Tomcat on their machine was to check it out and start it up. So each developer would have the complete system needed to do their work and could run their tests in isolation from other developers. Our CM person would do nightly builds and install them on a QA server (several servers actually). The QA team would use these servers as their test subjects. They would also have one server per tester so that when bugs were found they would have a good idea of what action cause the error (since they were the only person interacting with that server). Bugs would be reported quoting the build number that was attached to that build. Hope this helps. Regards, Pete. On Tue, 20 Nov 2001 15:21:55 +0100 "Laurent Michenaud" <[EMAIL PROTECTED]> wrote: > Ok, but i've got a lot of question about the organisation. > Here how i would see the cvs server for our case : > - There would be a cvs server with different branches( stable, > developpement... ) > - Each developper would get a version, work it on local and then update > it( i don't have > any ideas about the times per day of update ). > - Each developper would have a local tomcat on his machine( not very > good i think ). > - Our web server would check the cvs server for the latest stable enough > sources. > The tomcat on the web server would be used only for global testing. > Am i right ? > > Do u see others points ? > We have no experience at all about cvs in our enterprise and it's quite > worrying. > > a+ > > > > > De : Samuel Rochas [mailto:[EMAIL PROTECTED]] > Envoy� : mardi 20 novembre 2001 15:26 > � : Tomcat Users List > Objet : Re: CVS > > > Bonjour, > > Laurent Michenaud wrote: > > > > Would be CVS a good thing for our environnment ? > CVS, or any other configuration management tool is a must while having a > team working on a project. You can use some free tools, like the CVS > with clients like WinCVS. You can use some (mostly quite expensive) > commercial tools if you like. > > > Are there any model of organisation that we would use ? > all what you need is a file system and a network connection between the > users. > Take a look at http://www.gnu.org/manual/cvs-1.9/cvs.html and > http://www.cvshome.org/ > > Slts > Samuel Rochas > -- > SWIPe Software Engineering & Project Management GmbH > > Solutions with Individual Profile > > Web: http://www.swipe.de > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
