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

Re: Repository organization for complex project

From: BRM <bm_witness_at_yahoo.com>
Date: Wed, 13 Oct 2010 09:43:38 -0700 (PDT)

Mauro, Yes, such things are possible. I have a similar project and my repository is setup as follows: /<project> /<project>/libraries /<project>/libraries/<library> /<project>/clients /<project>/clients/<client> /<project>/server /<project>/tools /<project>/tools/<tool> /<project>/<other parts> (<project> is optional - as I have many different suites of projects, I do this.) Each of the following has its own trunk, branches, and tags namespace: /<project>/libraries/<library> /<project>/clients/<client> /<project>/tools/<tool> /<project>/<other parts> Projects under /<project>/libraries are utilized by all the other projects, and linked in via svn:externals. So, for example, a testClient would be stored at /myProject/tools/testClient and have its own trunk, tags, and branches namespaces, and it may link in the myProjectNetworkProtocol library from /myProject/libraries/myProjectNetworkProtocol; during development of the protocol it might use a branch of the myProjectNetworkProtocol library; during a merge it may use the trunk; otherwise it would use a release from under the tags. I have also found it useful to use the Revision number (as reported by svn info) of the last modification on a trunk in the name of the tag. For example, if myProjectNetworkProtocol was last modified at revision 5734 then its release tag would be /myProject/libraries/myProjectNetworkProtocol/tags/Release_5734, even if I was making the release at revision 15000. This is mostly just easier to track in the repository; though I don't usually need maintain older versions - things usually get moved to the latest version instead so I don't have to worry about releasing a modification to an older release; though if I did it'd probably become Release_<oldRev>_<newRev> for tracking purposes. We are also contemplating a namespace for system releases - that is, a release of all the parts under /<project>, likely in /<project>/system/tags; something to just say "these versions of all these parts go together". HTH, Ben From: Mauro Adolfo San Martin Ramas <msmartin_at_userena.cl> > >To: users_at_subversion.apache.org >Sent: Wed, October 13, 2010 12:05:43 PM >Subject: Repository organization for complex project > > >Hi, >So far I have been using svn in rather simple settings: at most some branches >and merges limited to one dev tree. > >However, now I need to set up a repository for a project composed by several >modules where different subprojects (comprised by subsets of modules) need to be >compiled and tested independently. Usually each team is actively developing only >one module but requires the latest (or stable) versions of some of the others to >build and test. > >For instance, if p_i are projects and m_i are modules, I need to configure svn >to support > m_1 m_2 m_3 m_4 m_5 >p_1 u u d >p_2 d u u u >p_3 u u d >... >where d means active development of module j by project i, and u only use. > >Is such a setting possible with svn? Any advice will be greatly appreciated. > >Best Regards, >Mauro San Martín > > >
Received on 2010-10-13 18:44:18 CEST

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.