Man, that sounds cool. :) ----- Original Message ----- From: "Peter Davison" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Tuesday, November 20, 2001 9:57 AM Subject: Re: CVS
> 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]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
