CODEWITHSUNDEEP
svnrepository
Rocklan
Rocklan

Reputation: 8130

SVN repository structure for a small company?

The repository design that I have setup at the moment is the standard approach:

Application1
    trunk
        DatabaseScripts
            CreateScripts
                CreateTable1.SQL
                CreateTable2.SQL
            StoredProcs
                StoredProc1.SQL
                StoredProc2.SQL
        Solutions
            MainSolution.sln
            Project1
                Project1.csproj
                Project1Class1.cs
            Project2
                Project2.csproj
                Project2Class1.cs
    tags
        1.0.0
        1.0.1
    branches
        developer1
        developer2

and repeat for each Application. This has served me well in the past when working on very large code bases.

However this company is quite small, at the moment there are about 8 apps, and each is reasonably small. There are only a few developers so rarely do we need to branch/tag.

The only problem that I have with the current setup is that if someone would like to check out the source code for all of our apps, the only way to do it is to either check out each individual app's trunk, one at a time, or check out everything and then delete the branches and tags.

So I was thinking about the following structure:

trunk
    Application1
        DatabaseScripts
            CreateScripts
            StoredProcs
        Solutions
            MainSolution.sln
    Application2
        DatabaseScripts
            CreateScripts
            StoredProcs
        Solutions
            MainSolution.sln
tags
    Application1
        1.0.0
        1.0.1
    Application2
branches
    Application1
        developer1
        developer2
    Application2

I notice that the SVN book has mention of this pattern, which they call "projects-as-branch-siblings": http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

Can anyone point out any deficiencies in this design other than those stated in the book?

Upvotes: 1

Views: 449

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97365

There are only a few developers so rarely do we need to branch/tag

Bad and wrong assumption, I have to say: I work solo, but have branches in order to have manageable code

One repo for all apps have one two three disadvantages:

  • Common revision history (number of revision isn't a sign of activity for single app anymore)
  • You give ability to merge (try to merge) unrelated URLs from different projects
  • *-hooks are global per repo, thus - you have to have more complex logic in it in order to differentiate actions for different apps in one common repo

Upvotes: 0

David W.
David W.

Reputation: 107090

The question I always ask: How you you do your releases?

For example: If each application is an independent release, then each application will have its own branching and tagging going on. Thus, each app should have it's own tags directory and it's own branches directory. This means each application has it's own trunk too. Thus:

app1
    trunk
    branches
    tags
app2
    trunk
    branches
    tags
app3
    trunk
    branches
    tags

However, if those apps are released as a single suite (think Microsoft Office), they'll share tags and probably branches too. And, they'll share a trunk. Thus:

trunk
    app1
    app2
    app3
branches
    app1
    app2
    app3
tags
    app1
    app2
    app3

Now, the question is about the database, and under what directory structure...

Databases are the trickiest part of release management because they involve more than just a bit of code. Each version of the application needs scripts that not only can create the database, but update it from any version. And, sometimes we have intermediate versions that require databases changes.

I found the easiest solution was to throw the requirement for these types of scripts onto the developer. We required the application to self update the database when it started. We used a version number in the database. Suddenly, database changes became a lot more rare and easier to handle.

The question is who is responsible for updating the database and the database scripts. I prefer the scripts to go under the app's directory because it gets versioned as the app does. However, if the database is almost a separate project (and maybe even a separate repository), I've seen it under it's own directory. Sometimes I see both: Some parts of the database development is under its own directory and some under the app:

database
    trunk
    branches
    tags
app1
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code
app2
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code
app3
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code

Sorry I can't give you a definitive answer, but the way you arrange your repository structure depends on how releases are done.

By the way, I always have a branches and tags directory although in very small shops, the branches directory is sometimes empty. It's there if you need it. If you don't, you don't branch.

In very small shops, branches sometimes get created after a release is out, and you do a hot fix. That's fine, you just branch from the release tag. No big deal.

Upvotes: 1

Related Questions