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

RE: Subversion Ideal repository layout

From: Choate, Bryan \(IHG\) <Bryan.Choate_at_ichotelsgroup.com>
Date: 2007-01-09 17:58:35 CET



I have a similar situation, actually. I chose to stick to the model of
having top level branches, tags and trunk directories in the repository.
When checking out, developers can essentially cherry-pick the trees they
want to pull so you shouldn't be concerned with a file overhead
difference between the two, and there will be less effort involved on
your part in branching and tagging. That's just my personal preference,


Hope this helps...




From: Vijay.Nair@iflexsolutions.com
Sent: Tuesday, January 09, 2007 6:53 AM
To: users@subversion.tigris.org
Subject: Subversion Ideal repository layout




I am a new Subversion user and am going to raise a question which
probably has been answered umpteen times and I have seen a lot of best
practices out there too. But I still hope to receive less flame and some
practical answers about this


So here goes...


We are building a huge web application which essentially consists of
separate modules (lets say...Order Management System, Portfolio
Management System etc..). Each of these modules can be shipped
separately or as a single cohesive unit. Also these modules will be
built on a common set of frameworks (Logging, Security,
Transaction...the usual). The frameworks are also part of a single
module simply called the framework module


Should we go in for a one "trunk" - one "branch" (for releases) - one
"tags" folder for all the projects combined or for a one "trunk", one
"branch" and one "tag" folder structure per project. Would the release
cycle get cluttered in the second option which is of my opinion ?


Any answers would be greatly appreciated.


Received on Tue Jan 9 17:59:05 2007

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.