svn folder structure organization

Question

One of my web apps has grown over the past few months from a single project file to include several class libraries. The svn structure has sort of grown organically and looks something like this:

repository-root
    site1
        trunk
        tags

    site2
        trunk
        tags

    library1
        trunk   
        tags
        ...

    library2
        trunk

Now that development is ramping up, I'd like to have something like this

repository-root
    site1
        trunk
        tags
           release-20100922
             site1
             library1
             library2
             ...
           release-20110101
             ...

Now, since Site1 and Site2 both reference the class libraries library1 and library2, what's the best way of going about reorganizing the folder structures so that

• Tags of each site contain a frozen copy of the associated class libraries at the time the site tag was created, and
• Each site can still reference the class libraries without having to have a separate copy in each site's trunk

I may just be thinking about this wrong. Suggestions?

Answer 1

Without doing anything special, a possible Subversion directory structure could look like this:

repository-root
    site1
        trunk
        tags
            release-20100922
                site1
    site2
        trunk
        tags

    library1
        trunk   
        tags
            release-20100922
                library1

    library2
        trunk   
        tags
            release-20100922
                library2

You and your developers would have to make sure that you create a consistent release tag on all of the components in a release.

Somewhere under the site1 release-20100922 tag, you could have a txt file that lists the libraries included in the release.

You can structure your tags like you outlined. It would be a manual process, but it can be done.

Answer 2

I had a similar problem and solved it by using this repository structure:

repository-root
    trunk
        site1
        site2
        library1
        library2
    tags
        site1
            release-20100922
                site1
                site2
                library1
                library2
        site2
            release-20110101
                site1
                site2
                library1
                library2

Each time I make a release I copy the whole trunk to a new tag. The first subdirectory of tags shows me for which site I made the release. This way I have no problems to identify the correct revisions of the libraries.

Yes, for a release of site1 I have tagged site2, too. But hey, tagging is cheap with subversion.

Answer 3

svn:externals as "soft source control link" in modular applications.

svn:externals can help you avoid some manual tasks and give a clear idea on what is what (and in what version).

You have several kinda "independent" products called "sites" that rely upon libraries. You got relase cycles for your products AND for your libraries as well. For increased stability you might not want to work with trunk library code anywhere as it might break not only one but multiple sites. On the other hand in more agile approaches a "break early, break often" could be desirable. So having the choice what library code version to use in your mainline development would be a plus.

Additionally your stabilizing/incubation branches (if any in the future) might want to sync with one specific version of the libraries so that reinforced compatibility will be transported into the resulting tags as well.

I would suggest the following Layout:

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.0"
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
    library1
        trunk   
        tags
            1.0
            2.0
            ...

There is no need to merge or move arround library source code when you change your mind and decide "Hey using the new 2.0 library1 API in our trunk was a piece of cake maybe we should use the trunk in the future.".

Lets imagine there is a bug in "library1 1.0" so you release "library1 1.1". You will need to make a new bugfix release of your main application as well and ship it out. so you update your "site1 2.0" maintenance branch, test and create a tag.

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.1" (changed the property)
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.2
                mycode
                library1 -> external of "library/tags/1.1" (inherits property change)
    library1
        trunk   
        tags
            1.0
            1.1
            2.0
            ...

Externals insure that YOU have the choice as to what library changes you want to incorporate and WHEN you want it. This will help to reduce "surprises".

Be aware though that svn:externals slow down your "svn update" commands with each external that has to be checked. Code is underway to improve that though.

Check out the silverstripe public repository for how they are doing things. Works well for them.

svn propget svn:externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/

Hope I could help