subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <bm_witn...@yahoo.com>
Subject Re: Repository organization for complex project
Date Wed, 13 Oct 2010 16:43:38 GMT
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@userena.cl>
>
>To: users@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
> 
> 
> 
Mime
View raw message