We have been using CVS for a long time now and want to move to SVN.  We have an 
empty SVN repository created but have questions on how we should set up our 
multiple projects that all utilize a common project in conjunction with tags, 
branches, releases.  

To keep things somewhat consistent between the CVS/SVN, we know we want to 
first separate between python and Java (our 2 development languages).  I 
believe our first SVN decision would be to have two separate repositories for 
these technologies and have multiple projects in these repositories.  FYI: Java 
and Python are completely separate code bases, are not dependent upon one 
another, and have a different release.

Now within each of these repositories, we both have a common utility project 
and multiple product projects.  When we release/tag a product, we would like to 
release/tag only the common and specific product (or does it matter?).

We have done some research SVN but are looking for best practices based on our 
requirements.  We were hoping that someone might be able to point us in the 
right direction/place of information on achieving a manageable/effective source 
repository and build management. 

I have reviewed Wicket's project hierarchy and seems relevant to ours.  
However, when wicket is built/released, all projects are tagged and built which 
is contrary to our goal.

We use Maven and its project structure.  Our common project is a referenced 
module in each product project.

Which of the following options is recommended?
Are there any good specific references that would help determine this?  (we 
have googled but a lot of information is returned)
I did find this link which was helpful:  
http://svnbook.red-bean.com/en/1.1/ch05s04.html which is why we are leaning 
towards Option B.

Option A:

<repo>/java
     + trunk
            + common
            + project 1
            + project N
     + tags
            + common
            + project 1
            + project N
     + branches
            + common
            + project 1
            + project N
     + releases
            + common
            + project 1
            + project N

Option B:

<repo>/java
       + common
             + trunk
             + tags
             + branches
             + releases
       + project 1
             + trunk
             + tags
             + branches
             + releases
       + project N
             + trunk
             + tags
             + branches
             + releases

Option C: (this option is a separate repo for each project)

<repo>/java/common      
         + trunk
         + tags
         + branches
         + releases
<repo>/java/project1      
         + trunk
         + tags
         + branches
         + releases
<repo>/java/project2      
         + trunk
         + tags
         + branches
         + releases


Thanks in advance!
- Doug

Reply via email to