tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry White" <barrywh...@charter.net>
Subject Re: CVS
Date Wed, 21 Nov 2001 03:01:59 GMT
Man, that sounds cool.
:)
----- Original Message -----
From: "Peter Davison" <peterdavison@home.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
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" <lmichenaud@adeuza.fr> 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:samuel.rochas@swipe.de]
> > 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:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> > Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>
> >
> >
> > --
> > To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> > Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>
> >
>
> --
> To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
> Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>
>
>


--
To unsubscribe:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands: <mailto:tomcat-user-help@jakarta.apache.org>
Troubles with the list: <mailto:tomcat-user-owner@jakarta.apache.org>


Mime
View raw message