views:

67

answers:

3

Hi Everyone,

I've been given the task of restructuring our Repositories upon moving to SourceGear Fortress (for those that don't know this product, think Stable, Reliable SourceSafe on Steroids :P)

I know how I'm going to organise all of my projects and solutions, the problem that I'm having is how to organise these into repositories. Do I have just one? or do I have one per project? or one for web applications and one for winforms etc?

One thing that we would like to be able to do is to maintain a central library of reusable (or 'common') components and branch them into the projects that need them, which may be in another repository.

Any thoughts greatly appreciated :D

Jason

A: 

I can't give a definitive answer since I'm not familiar with that SCM, but most SCM's have advantages to one way or the other. Some work better with more repositories. Some work better with a single repository and more branches. Usually the documentation will point you in a preferred direction.

You need to consult the documentation for the SCM and apply its recommendations to your workflow.

Wade Williams
+1  A: 

SVN is pretty much the only version control software I have alot of experience with. For that tool, I find it better to have one repository. Some of the benefits are:

  • Revision history all the way back to the beginning for source files that are moved or copied. I have had more than one occasion where I wanted to completely reorganize a project/library by splitting it up. If I had one such library in its own repository, I would have to break it up into two new libraries/repositories and would not easily be able to preserve the history for each file easily if at all.
  • If you have a project with dependencies on other projects in the repository, you always know what versions those dependencies were at for any version of the project in question.
  • It's also convenient to be able to look at one log history that shows changes for all projects through time. You should be able to easily view log entries that only apply to a specific area of the repository though. SVN does this.

If your version control system can do those things and still keep everything in separate repositories then go for it. Hope that helps.

Arnold Spence
+1  A: 

If they are in different repositories, your build file for each project will get more unwieldy since it has to maintain the different repository paths and possibly versions for common components.

If they are in one large repository, breaking the build becomes a company-wide problem especially in updating the common components. I've read that companies (like Google) who have this type of large repository have a culture of fixing breaks in all the projects affected by a change in a common component.

Also, performance can become an issue with large repositories. I've had experience with large svn repositories becoming unwieldy and I know Google uses its hive mind to keep their's going. http://www.perforce.com/perforce/conferences/us/2007/index.html#installation

SargeATM