1

When having several related projects (identifiable, stand alone applications, that share libraries), how do you prepare your SVN server directory structure? By branch > project? By project > branch? Something entirely different? Or is it better to have one SVN server for every project? (Take into account that some projects are intimately related)

Jon Hopkins
  • 2,243
  • 25
  • 28
Esteban Küber
  • 36,388
  • 15
  • 79
  • 97

9 Answers9

10

The standard convention is

  • project1
    • branches
    • tags
    • trunk
  • project2
    • branches
    • tags
    • trunk

inside a single repo. Since that's the most common convention, some tools just expect your projects to be laid out like that.

Which projects belong in which repo is more of a judgement call. Personally, I'd start with one repo for all projects managed by the same group, e.g., team, division, or company.

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • As I'm accepting this answer, I guess I should add the link with information to `externals` http://svnbook.red-bean.com/en/1.0/ch07s03.html as it's useful for having coordinated different servers. (Taken from http://stackoverflow.com/questions/1138628/how-do-you-arrange-several-projects-in-a-single-svn-server/1138717#1138717 ) – Esteban Küber Jul 26 '09 at 17:18
7

Check out the subversion book, which offers a section on Recommended Repository Layout

Matthew Vines
  • 27,253
  • 7
  • 76
  • 97
2

This question gets a whole section in the SVN book. I would recommend starting there, and asking about anything it doesn't make clear or is specific to your project.

Kevin Peterson
  • 7,189
  • 5
  • 36
  • 43
2

I'd look into using externals . If you have many related projects that all use the same codebase, but you don't want to copy that codebase into each repository, set up an external link in each repository to point to the common codebase.

bkritzer
  • 1,418
  • 3
  • 16
  • 27
1

  • root / trunk / projectfolders

  • root / branches / projectfolders

That way someone can get all the mainline projects without getting any branches if so desired.

NikolaiDante
  • 18,469
  • 14
  • 77
  • 117
1

For projects that are intimately related, I recommend:

root > branch > project

This way it's possible to check out a single branch and get all of the code that's current in that branch.

JSBձոգչ
  • 40,684
  • 18
  • 101
  • 169
1

As someone who maintains large svn repos, let me tell you, DO NOT use a unified trunk. It will make all operations much, much slower. Beyond this, extracting a single project out of a larger repo is not only tedious and touchy, but will result in a space waste when you do eventually want to peel away even one project.

Use separate repos for each project, with a trunk and tags directories under the repos, and have developers needing to tie to other projects use externals, the way they were designed.

Lazy is not an adequate substitute for organized.

markh
  • 783
  • 4
  • 10
0

I use a folder for each project, then branches within each folder. This way if a different team is working each project, they don't need to see the whole tree, just their branch.

Dan Lorenc
  • 5,376
  • 1
  • 23
  • 34
0

We've setup repositories for each project, thus each can have their own branches/tags etc.

Also, for interdependent projects, you can setup linked repositories so that the files can be shared. This has worked well for us so far and has proven to be quite flexible.

Mat Nadrofsky
  • 8,289
  • 8
  • 49
  • 73