CODEWITHSUNDEEP
svnversion-controlproject-organization
Manu13
Manu13

Reputation: 71

with Subversion, how to manage version of component in a multiproject repository?

Imagine an organization of a repository like this:

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-2.0
           /trunk
/Module2/branches
           /tags/Rel-1.0
           /tags/Rel-1.1
           /tags/Rel-1.2  
           /tags/Rel-1.3
           /tags/Rel-2.0
           /tags/Rel-2.1         
           /trunk

The project1 is using Module1 and Module2. The release 1.0 of project1 is done by using release 1.0 of Module1 and Module2.

The new release of project1 (named for example 1.1, not a major evolution) is done by using Release 2.0 of Module1 and 2.1 of Module2.

How can do this by using subversion.

Upvotes: 2

Views: 598

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97282

I'll suggest reorganisation of repo by splitting to separate repos for each "entity" (Project, Module1, Module2,...,ModuleN) and use svn:externals in Project repo for all modules instead of direct embedding code.

At development stage externals refer to HEAD of external repo, in every release of Project (marked as special tag, yes?) before tagging Project you have to edit and freeze externals to some fixed revision of included modules.

Pro

  • you'll separate deleopment history (in terms of SVN) into independent sub-parts
  • for every tagged release linked versions of modules are easily identifiable
  • repos will have more a simple code-tree
  • /something forgotten/

Contra

  • history of project will not be transparent due to the presence of a bifurcation point and work with ancient revisions (before bifurcation) will give (can give) some headache

Upvotes: 1

chabicht
chabicht

Reputation: 107

I would try to solve dependency management outside SVN (think of Apache Maven or Ivy in the Javaverse).

If it has to be SVN, how about special tag names? So you could introduce a convention that your build system looks in special folders for versions it depends on, like /Module1/branches/deps/Project1/Rel-1.0 for the code your Rel-1.0 build of Project1 needs.

/Project1/branches
          /tags/Rel-1.0
          /trunk
/Module1/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.0
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk
/Module2/branches
           /tags/Rel-1.0
           ...
           /tags/Rel-2.1         
           /deps/Project1/Rel-1.0
           /deps/Project1/Rel-1.1
           /trunk

You could create the folders for dependents by referencing to the tag folders:

# dependencies to Module1
svn cp http://myServer/svn/Module1/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# dependencies to Module2
svn cp http://myServer/svn/Module2/branches/tags/Rel-1.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.0
svn cp http://myServer/svn/Module2/branches/tags/Rel-2.0 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

Switching versions later would look like

# delete old reference
svn rm http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1
# make other one for new version
svn cp http://myServer/svn/Module1/branches/tags/Rel-2.1 http://myServer/svn/Module1/branches/deps/Project1/Rel-1.1

The downside of this approach could be more space requirement for SVN working directories.

Upvotes: 1

Related Questions