Question

We are moving to SVN from VSS and are debating the project structure.
We are debating two proposals displayed below.

No. 1 seems simpler for development support since a Project release version is tied to a
tag and the developer would only need to perform an update on that tag to immediately get to work.

No. 2 insures that all Projects and Dependencies can be developed independently but
building a particular release version means knowing the tags of the Project and all
it’s Dependencies.

Are there obvious comparative benefits between the two?
Any gotchas in the two structures? or are there better structures out there?

1.
Development  
  + trunk  
    Project1  
    Project2  
    Dependency1  
    Dependency2  
    Dependency3  
  + branches  
  + tags  

2.
Project1  
  + trunk  
  + branches  
  + tags  
Project2  
  + trunk  
  + branches  
  + tags  
Dependency1  
  + trunk  
  + branches  
  + tags  
Dependency2  
  + trunk  
  + branches  
  + tags  
Dependency3  
  + trunk  
  + branches  
  + tags  

Answer 1

In general, I recommend having projects remain separate as much as makes sense (your second option). This will generally promote reuse. (If I only want Dependency2, I don’t need to bring an entire other project in order to get to it.)

However, you have to be smart about what your dependencies are really going to be doing. For example, if Dependency2 is only going to be a dependency for Project1, then it should probably just exist within Project1’s source structure. (Note: I do not mean have separate branches and tags for the Dependency – I mean have it be in a different package, or another subproject within Project1.)

If you want to make a project a reusable library within your organization, then have it as a separate project completely so you don’t introduce unnecessary co-dependencies. And, I would encourage your development team not to check out a dependency and work alongside that. Instead, build the dependencies and use them as a binary library. This way, whoever checks out a Project to work on it will always have the latest library dependency that they need for the application. If an update is needed, then you can worry about checking out the Dependency and building it. (Or, even better, have a location where project teams can release the latest libraries as binary files.)

Update on Versioning of Project and Dependencies
If you go with the #2 route, and have separate Project and Dependencies, your versioning actually becomes very simple. Here is an outline of how it might work.

1. Team A is working on Project1.
2. Team B is working on Dependency1 which Project1 depends on.
3. Whenever Team B finishing their work, they build a release of Dependency1 (a binary – perhaps a DLL, or a library, or something along those lines). They can also tag their project at this time. The binary name may be: Dependency1-v1.0.0
4. Team A takes the binary release of Dependency1-v1.0.0 and includes it in their project. (Typically, binaries are kept in a /lib folder or something like that within the project.)
5. Whenever Team A finishes their work, they can release their project and tag their project as well.

Note that, at no point, does Team A check out the source code from Dependency1 and bring it into their project. This allows development of the two projects to remain separate so that there is autonomy between the development teams. Team A can use the binary for as long or as short as they like. If they want an updated version, they go get the latest release from Team B.

This process is not really much different from what you would do if you were using a library from an outside source. You have no control over how they version their library, so you just grab what you need for your project and update when you feel is necessary. You keep the binary within your own project structure so that you can always rely on it.