We're using subversion for several j2ee projects. For the most part, the
subversion part of the repository organization is, for us, just not that
different. We do this:
Repository Root (one repository per project)
- trunk
- branches
- tags
Thatıs the layout recommended by most and using it makes life with
TortoiseSVN very, very sweet.
We do the usual stuff there: commit all the main stuff to the trunk, create
branches for small development efforts we want off the trunk for awhile (and
then merge them when we're done) and snapshot the trunk occasionally for
releases with a "tag".
As for j2ee organization...
Our "dev" directory (the directory structure we maintain as the "trunk"
looks like this:
build.xml
web
TODO.txt
subprojects
src
sql
nbproject
conf
lib
Notably...
"web" contains all front-end stuff: html, graphics, jsp pages, velocity
templates, etc. as well as WEB-INF/web.xml (but no other WEB-INF resources
besides web.xml).
"src" contains all the java source code.
"conf" contains all our configuration related files (datasource.properties,
spring applicationContext.xml, WebWork's xwork.xml, etc.). The IDE
(NetBeans in this case) is configured to copy all the files out of conf into
the WEB-INF/classes when it builds the app.
Lib contains all the libs we rely on with a README file that explains those
dependencies and some more organization fluff to help make dependencies
obvious.
I see little point in a shared "lib" directory. Disk space is dirt cheap so
that's no motivator to consolidate shared libs into a central directory. As
for central update-ability, I vastly prefer to just copy updated libs I know
I need/want into each project individually. If I need to update a lib, I
replace it for each project individually, not globally. The last thing I
want is to drop a new lib version into some "shared" lib directory and have
it break every project we have due to some "new feature". I'd rather have
it break one project at a time in a more managed way. Maybe that's just me.
"sql" contains a DDL script for each and every SQL action we apply to the
database. From the initial table-creation scripts, to table updates, to
data-inserts (if they are a part of the project). This way the repository
versions our SQL commands as well as the src. Some people disagree with
managing their database this way, search for past posts on "sql" for the
thread.
This is, mostly, the directory structure assumed by NetBeans. It wasn't
what I used originally (I had my own layout) but it's close enough to what I
had that using it isn't cumbersome. Eclipse makes different assumptions
about their "preferred" locations for things so if you're using Eclipse
you'll probably want to go that route.
All the above stuff is repository independent. It's just how we organize
the app within the "root" directory (the trunk) that the repository
maintains. We can change that j2ee layout at any time without any
repository modifications.
Which is all a very long winded way of saying, we just setup our repository
with:
trunk
branches
tags
And we one repository per project.
:-)
Hope that helps.
- Gary
On 2/7/05 10:55 AM, "Eric Martin" <subversion@emalbum.com> wrote:
> Hello,
>
> I am going to use Subversion for my J2EE web applications and was hoping
> that other J2EE developers could share some insight into a suggested
> repository layout. I have looked over the Subversion book, and am just
> looking for input from others who have used Subversion for J2EE
> development. I have been looking for some \"best practices\" in regards to
> this issue, but have not been able to find anything.
>
> Thanks in advance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 14 09:32:32 2005