[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Best way to set things up for subversion, J2EE (tomcat) and JSPs

From: Nick Burch <nick_at_torchbox.com>
Date: 2005-04-27 18:27:26 CEST

Hi All

Despite some fun hours reading the Turtle subverion book, and the
Pragmatic subversion book, with a bit of google for good measure, I can't
seem to find anything describing how best to migrate my current setup to
subversion. Perhaps someone has a good scheme?

We write code for either ColdFusion or J2EE (on Tomcat). For both, we
currently opperate a pessimistic locking scheme powered by RCS. (We have a
fancy web front end that changes file permissions on checkout/in, so you
can only edit a file once it has been checked out by you. It also handles
checking someone else's file back when they're on holiday). People can
access their files on the server, or over network shares, all of which
honour the permissions.

The advantage of this scheme is that we only have one copy of every file,
and it's the live one. When you edit a JSP (or coldfusion file), you can
see you change straight away. Since these files don't require a compile
step, it means our developers (esp. the graphic ones) don't have to go
through lots of hoops to see and test their changes.

(Admitedly, for our java code, only one person can edit it at once, and
you need to be connected to the server to edit, which is why were are
looking at subversion. Also, if you check out something core and break it,
it breaks everything, but we have procedures for dealing with this)

If we move to subversion, I'm not sure how it would work for say a bunch
of jsps. (I'm happy about how to do things for servlets, beans etc, and I
can see a clear win for them)

One option would be for everyone to check out their own copy of everything
to work on. This would either require us to install tomcat+coldfusion on
everyone's machine, or to be very careful with how paths are used (so we
can have "project" check out as project_nick and project_bob under the
webroot, with everyone hacking on their own one). The trouble with this is
it'll require lots of setup to get each instance working, and we have to
be careful to use relative paths.

The other is to check out the code to each developers directory, have them
change it, then commit + have the commit stage push it out to the server.
It means that if a graphics guy is testing some small tweak, he has to do
lots of things to see his change, while now he just saves a change and
hits refresh in his browser. This would seem to be a big step backwards.

I think the reason I'm having issues is because I'm dealing with
compiled-on-demand code, running under an environment where setting up a
new application isn't always very quick. Subversion seems to assume that
having checked out a working copy, doing something with it and seeing if
it works is quite easy, but that doesn't seem to be the case for me.

So, what are people doing for things like jsps with several developers?
What's the trick that I'm missing?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 27 18:59:26 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.