Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do you structure your SVN repository? [closed]

What is better?

A:

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B:

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

What repository structure do you use and WHY?

like image 603
Juve Avatar asked Sep 30 '08 09:09

Juve


People also ask

How do I restrict access in SVN?

As @jpierson already answered, you can use authz files to define No Access, Read Only or Read Write rules on repository paths. Repository path can represent repository root and any path within repository. I.e. you can specify access rules not only subtrees (folders) but files as well.

How does SVN repository work?

A Subversion repository — abbreviated SVN repository — is a database filled with your code, files, and other project assets. A SVN repository maintains a complete history of every change ever made.


2 Answers

We use A, because the other one didn't make sense to us. Note that a "project" with regard to SVN is not necessarily a single project, but may be several projects that belong together (i.e. what you would put into a Solution in Visual Studio). This way, you have anything related grouped together. All branches, tags and the trunk of a specific project. Makes perfect sense to me.

Grouping by branch/tag instead does not make sense to me, because the branches of different projects have nothing in common, except that they're all branches.

But in the end, people use both ways. Do what you like, but when you decided, try to stay with it :)

As an addition: We have separate repositories per customer, i.e. all projects for a customer are in the same repository. This way you can e.g. make backups of a single customer at once, or give the source code of anything the customer owns to him without fighting with SVN.

like image 169
OregonGhost Avatar answered Oct 11 '22 09:10

OregonGhost


The Repository Administration chapter of the SVN book includes a section on Planning Your Repository Organization outlining different strategies and their implication, particularly the implications of the repository layout on branching and merging.

like image 35
Mihai Limbășan Avatar answered Oct 11 '22 09:10

Mihai Limbășan