- How the CVS server gets organized is based on preference, in my experience. Usually, I've seen a "branch" for each individual project and then another one for your organization's library of known stable code (connection mgr, XML utilities maybe, etc)
- When you say that "each developer would get a version", I'm assuming you're saying each developer would get their own version of CVS which is true...sort of. They'd get their own CVS client, but not necessarily their own CVS repository. Everyone gets access to a shared CVS repository. - I disagree that it's bad to have a Tomcat instance on each workstation (unless your workstations are incredibly underpowered). Giving each app. developer their own private development environemnt is common practice. It allows me as the developer to play w/ things that may reduce the efficiency of the entire team. For instance, say I need to bounce Tomcat alot throughout the day for whatever reason. If I do this, people who are testing their changes may be constantly interrupted by me bouncing Tomcat. The challenge to this development paradigm is that creating a new developer environment is always a hassle (setting up Tomcat, db connections, db layout, etc so that it's perfectly aligned to the staging/production environment). Keeping everyone's code in sync can be a challenge as well...Ant can come in handy in this situation. - Depending on how it's setup, I would recommend against having the webserver automatically deploy the most recent code in CVS. The process, to me, just seems too error prone. There could be exceptions based on the environment, but in general I believe that code should only find it's way to the production environment when it's been specifically requested by the appropriate person/people. - Tomcat could be a great tool for testing. I'd recommend for a Staging and separate Production environment. A Production environment is where the code sits when it's in day-to-day use. A Staging environment is (or at least should be) identical to your Production environment, but is specifically intended for testing purposes - not daily usage. I may get flamed for this, but if you're organization is small you may want to consider M$'s Sourcesafe. It's concepts may be a little bit easier to adapt to if you have no experience w/ CVS. CVS is a great and powerful tool, but if you have no experience w/ it, you could run into some serious migration problems. ----- Original Message ----- From: "Laurent Michenaud" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Tuesday, November 20, 2001 6:21 AM Subject: RE: CVS 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]>
