How do you organize your version control repositor

Question

First, I know about this: How would you organize a Subversion repository for in house software projects? Next, the actual question: My team is restructuring our repository and I'm looking for hints on how to organize it. (SVN in this case). Here's what we came up with. We have one repository, multiple projects and multiple svn:externals cross-references

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

To clear the vocabulary: Solution means single product, Project is a Visual Studio Project (that results in a single .dll or single .exe)

That's how we plan to lay out the repository. The main issue is, that we have multiple Solutions, but we want to share Projects among Solutions. We thought that there is no point really in moving those shared Projects to their own Solutions, and instead we decided to use svn:externals to share Projects among Solutions. We also want to keep common set of tools and 3rd party libraries in one place in the repository, and them reference them in each Solution with svn:externals.

What do you think about this layout? Especially about the use of svn:externals. It's not an ideal solution, but considering all pros and cons, it's the best we could think of. How would YOU do it?

Answer 1

We've set ours up to almost exactly match what you've posted. We use the general form:

\Project1
   \Development (for active dev - what you've called "Trunk", containing everything about a project)
   \Branches (For older, still-evolving supported branches of the code)
       \Version1
       \Version1.1
       \Version2
   \Documentation (For any accompanying documents that aren't version-specific

While I suppose not as complete as your example, it's worked well for us and lets us keep things separate. I like the idea of each user having a "Thrash" folder as well - currently, those types of projects don't end up in Source control, and I've always felt that they should.

Answer 2

Why have it all in one repository? Why not just have a separate repository for each project (I mean "Solution")?

Well, at least I've used to the one-project-per-repository-approach. Your repository structure seems overcomplicated to me.

And how many project do you plan to put into this one big repository? 2? 3? 10? 100?

And what do you do when you cancel the development of one project? Just delete it from repository tree so that it will become hard to find in the future. Or leave it lying around forever? Or when you want to move one project to another server altogether?

And what about the mess of all those version numbers? The version numbers of one project going like 2, 10, 11, while the other goes like 1, 3, 4, 5, 6, 7, 8, 9, 12...

Maybe I'm foolish, but I like one project per repository.

Answer 3

I believe that Pragmatic Version Control using Subversion has everything you need to organize your repository.

Answer 4

I think the main disadvantage of the proposed structure is that the shared projects will only be versioned with the first solution they were added to (unless svn:externals is fancier than I am imagining). For example, when you create a branch for the first release of Solution2, Project1 won't be branched since it lives in Solution1. If you need to build from that branch at a later time (QFE release), it will use the latest version of Project1 rather than version of Project1 at the time of the branch.

For this reason, it may be advantageous to put the shared projects in one or more shared solutions (and thus top-level directories in your structure) and then branch them with each release of any solution.

Answer 5

RE: the relative path and shared file issue -

It seems that this is svn specific, but that is not a problem. One other person already mentioned separate repositories and that is probably the best solution I can think of in the case where you have different projects referring to arbitrary other projects. In the case where you have no shared files then the OP solution (As well as many others) will work fine.

We're still working this out and I have 3 different efforts (different clients) that I have to resolve right now since I took over setting up either non-existent or poor version control.

Answer 6

I have a similar layout, but my trunk, branches, tags all the way at the top. So: /trunk/main, /trunk/utils, /branches/release/, etc.

This ended up being really handy when we wanted to try out other version control systems because many of the translation tools worked best with the basic textbook SVN layout.