specific subversion repo layout in company

Question

First I'll explain some history of using Subversion in our Company. We started using Subversion around 3 years ago. We use it with TortoiseSVN as Client.

We have 3 repositories with totally different projects who don't have anything in common.

But in 1 repository we have about six products/projects who share common dll (for zipping, xml, basetypes, etc) We have around 20 of these common dll (who are still being updated).

So these 20 Common Dll are in the trunk together with the six projects who need them.

Now the trunk is really getting filled and the drawback of these is that all projects rely on each other. So if changes are done in 1 common dll for one project, then all other projects need to update and need to be adapted and validated .

Since this is not that handy (specially when you want to release a product and then some new changes come in from other products) we thought to splice up everything per project. Still keeping the big trunk to synchronize between the different projects.

So we create trunk/branches/tags folder per project and do a svn copy of only the dll needed for that project.

Situation:

Before:

  -branches
  -tags
  -trunk
      -Common DLL 1
      -Common DLL 2
      -Common DLL 3
      -Common DLL 4
      -Common DLL 5
      -Project 1
      -Project 2
      -Project 3

Now

  -Projects
      -Project1
          -branches
          -tags
          -trunk
              -Common DLL 1
              -Common DLL 2
              -Project1
      -Project2
          -branches
          -tags
          -trunk
              -Common DLL 2
              -Common DLL 3
              -Common DLL 4
              -Project2

The advantage of this approach is that you have better overview what dll the different projects have and you can check out each separate project as Fully recursive in stead of partial checkout. We also have more control in when we do the synchronisation of the common dll (important for releases) and we don't have unfinished work commits from other project developers.

HOWEVER: we do have a lot of problems merging these Common Dll. With (latest) TortoiseSVN we have constantly "tree conflicts". Also a lot of merging problems (sometimes going back for more than a month and not remembering what really changed).

Also renaming dll goes wrong and Tortoise always add all the trunk dll not yet in the project to the working copy of this project. Then you always have to manually delete these before checking in.

I know we should never use "Reintegrate a branch", but there are two options left. Anyone knows which one is best?

Can we keep up this repo structure or should we change it. Is it better to put all Common Dll in another Repo and then using externals?

thx

Answer 1

I think the second approach is much better than the first one. But little bit hard to manage in the first place.

Answer 2

Is it better to put all Common Dll in another Repo and then using externals?

Not necessarily "another repo", but you should definitely treat it as a project that stands on its own. Your layout should look like this:

  -Project1
      -trunk
      -branches
      -tags
  -Project2
      -trunk
      -branches
      -tags
  -CommonDLL1
      -trunk
      -branches
      -tags
  -CommonDLL2
      -trunk
      -branches
      -tags
   -...

Then Project1/trunk would probably have a svn:externals property with this content:

-r148 ^/CommonDLL1/trunk CommonDLL1
-r157 ^/CommonDLL2/trunk CommonDLL2

This property causes subversion to automatically create the folders CommonDLL1 and CommonDLL2 inside your working copy of Project1/trunk whenever you do a checkout or update.

Note how the externals definition contains a revision number. This ensures that if you change something in CommonDLL1, this will not affect Project1 until you explicitly change the revision number in the externals definition. This is especially important for the immutability of your project tags.

There are some downsides to this approach which you have to weigh against the upsides:

• If you make a change to CommonDLL1 by committing via a working copy of Project1, you might be confused when the change mysteriously disappears after an update. This is because SVN will not automatically adjust the revision number in the externals definition. You have to explicitly change it and commit that change also. Educate your team about this.

• Your continuous integration server will not automatically discover that the latest Project1/trunk no longer builds against the latest CommonDLL1/trunk. You will only find out about that when you change the revision number in the externals definition.

Answer 3

The tendency is to split things into (sensible) logical, freestanding units. Interestingly, the Git DVCS has increased the awareness: people wanting to checkout just /trunk/project were faced with the impossibility of doing so, and the general response has been to chop up projects (counts as a freestanding unit) into its own repo.

While such finely-grained packages (the "/project/trunk" approach) involves a bit more work, the independence of each component plays out for people in the end. The decoupling of projects/code leads people to think more about APIs and interaction. In other words, it is possible to not need to know of the entire picture anymore and be able to concentrate on a few components only.

See Xorg which employs this scheme of split repositories (in the sense of each having its own master/trunk).

For you that means: Your "now" state matches this very description. It is a pity TSVN can't deal with the repository state however; bad tool interaction combined with the design decisions SVN made a few years ago.