Menu
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?
603
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.
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.
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.
169
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.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
