Hi Stefan and Ryan,
Thanks for the quick response. :-)
On Tue, Mar 23, 2010 at 03:30:20PM +0100, Stefan Sperling wrote:
> > > We have an application which consists of multiple modules which are
> > > packaged together, then installed into a Web-application layout. That
> > > is: The repository layout differs from the final installed application
> > > layout (files are distributed across the whole installation at various
> > > places).
> > >
> > > For example, consider the following repository structure (I'm making
> > > this up for simplicity):
> > >
> > > /trunk/module1/jsp/something.jsp
> > > /trunk/module1/java/com/c4u/module1/Someclass.java
> > > /trunk/module1/sql/create_scripts/sometable.sql
> > > /trunk/module2/jsp/anotherthing.jsp
> > > /trunk/module2/java/com/c4u/module2/Anotherclass.java
> > > /trunk/module2/sql/create_scripts/anothertable.sql
> > >
> > > After repackaging and installing, these files are arranged like this:
> > >
> > > webroot/jsp/c4u/module1/something.jsp
> > > webroot/jsp/c4u/module2/anotherthing.jsp
> > > webroot/WEB-INF/classes/com/c4u/module1/Someclass.java
> > > webroot/WEB-INF/classes/com/c4u/module2/Anotherclass.java
> > > sql/c4u/module1/create_scripts/sometable.sql
> > > sql/c4u/module2/create_scripts/anothertable.sql
> > You may want to look into file-level svn:externals available in svn 1.5 and later.
> > I'm not certain this will 100% deal with your situation, but it's the only solution that comes to my mind.
> File externals have several known issues and I would not recommend using
> them, ever, in their current implementation (the plan is to fix them
> eventually as part of the on-going working copy code rewrite).
> Using the hack you used in CVS will not work well with Subversion either.
> Some suggestions:
> 1) Change your way of doing things: don't develop
> within directories that are not under version control.
It's hard to do since we need that webapp structure to make Tomcat et al
happy while we still need modules (e.g. customer-specific) and it all
needs to be stirred together In The Right Way(tm)...
> 2) Have you considered if your problem can be solved by
> using directory externals?
We'd end up with a shadow copy of the installation in the repository
itself since externals are nothing more than directory properties,
am I correct? While this might work for customer projects (to have one
"master installation" inside the repository), it won't work for e.g. the
trunk where all modules are present and I only want a subset checked out
for a particular task (which means that, for example, I want
webroot/jsp/c4u/core/* and not webroot/jsp/customer1/someproject1/* -
with a lot of other similar cases spread across the installation).
When I tested externals it also looked like commits will not be atomic
either - each external reference is committed separately, right? It
looked like Subversion would first process "local" files first, then
> 3) Have you considered if your problem can be solved
> by versioning symlinks within Subversion?
We're looking into using symlinks to build the webapp structure and keep
the checked-out structure in parallel. We'll see how that works out in
Thanks a lot for your answers!
"What we nourish flourishes." - "Was wir nähren erblüht."
Received on 2010-03-23 17:32:44 CET