Suggestions for setting up a subversion repository

Question

Our team is just ramping up to use source control through SVN. We are currently using some test repositories for getting used to the process.

We're nearly ready to put this into full time use.

We build only small to medum/large web apps, most of which share the same core (but differnt on LAMP/Win), but are customized in some way. We will likely have hundreds of projects in the repository. Also, we usually do more than one project for one organization.

We have LAMP and Windows developers. ( I think this makes the question somewhat different than http://stackoverflow.com/questions/167014/best-practice-for-creating-subversion-repositories)

Do you have any suggestions on how to structure the repository?

Answer 1

I think a single repository (backed up, of course) with individual project directories below it should suffice:

/usr/share/code_repository
   /base
      /trunk
      /branches
      /tags
   /project1
      /trunk
      /branches
      /tags
   /project2
      /trunk
      /branches
      /tags
   ...

So base is the core code and project1, project2, ...projectN would contain the variations of the base. When you checkout projectN, you would also check out base and have links to base from within Project1.

An alternative to doing it this way would be to simply have one repo with the core in it and make a branch for each variation. That is, if the core is one, big chunk and your variations are really simply variations.

This seems more a question of code packaging architecture than version control structure.

Answer 2

The right answer is "Whatever works best for you".

There are people who will tell you of the advantages of this way over that way, but at the end of the day, having project->{trunk, tags, branches} or {trunk, tags, branches}->project, or if you have a releases branch or if you rename these to anything else or have other named items in there or remove some of the named items is all down to how you and your colleagues work and what fits best with your development cycle.

However, from what you have said I would suggest the following:

repository
    core
     trunk
     branches
     tags
    project1
     trunk
     branches
     tags
    project3
     trunk
     branches
     tags

The advantage of this is that you will be able to link each project to different versions of the core, which will be inside the core/tags folder while still allowing development of the core. This is only my suggestion. Your mindset may vary

Answer 3

Create different projects as different repositories (on same machine). So that you can control change mailing list for each project separately :)

Answer 4

It's a subjective question so you may want to modify the tags.

Assuming you're asking about development projects, you'd have to clarify as to what sort of development you're doing. Different languages or project types usually result in different "standards".

The traditional SVN structure as inherited from CVS is to have trunk, branches, and tags sitting in side the main project directory. That would be duplicated for every separate project directory.

For interdependent projects, I personally prefer

root/somepath
  trunk
    myproject
  branches
    branch1
      myproject
    branch2
      myproject
  tags
    tag1
      myproject
    tag2
      myproject

This makes it easier to check out all projects that are tagged with the same tag/branch.

But it's highly dependent on your build scripts and how you plan on having developers or users check out. What's best is what's logical and efficient for your projects.

Answer 5

How you structure your repo will probably depend a lot on the release cycle. When you do a new version of your common core, will you roll it out to all your customers at once? Or will you do incremental roll-out as each customer needs new features (and, therefore, has need of the new features in the core)?

If you'll roll out to everyone when you upgrade your core, then you probably want one set of branches/tags/trunk:

branches/
tags/
trunk/
    core/
    customer1/
        project1/
        project2/
    customer2/
        project1/
        project2/

The downside to this is that, if there's a lot of code for each customer, your checkouts would be huge, and you'd have to check out everything to be able to do anything (though svn 1.6 does give you the ability to check out a subset of the tree).

On the other hand, if the different customers will be released on different schedules, then you might prefer to have a top-level directory for each customer. You'd also want someplace to keep your common core.

core/
    branches/
    tags/
    trunk/
customer1/
    branches/
    tags/
    trunk/

If you do this, you'd probably want to look into svn:external so you get a copy of the common core whenever you check out customer1's source tree. This causes some issues when you want to branch or tag, though. (Which might be a reason to prefer the first option.)

If you haven't yet, read "Pragmatic Version Control Using Subversion". They have some examples of using externals, which might help clarify which scheme you want to use.

Answer 6

The great thing about subversion is that you don't really have to care about that so much in the beginning.

Because you can move around files and folders inside the repository without losing their history, you could just start out with whatever you think is right and see if it works for you.

If it doesn't it can be changed later without too many problems.