What is the reasoning behind the recommended layout for Subversion repositories?

Question

Version Control with Subversion recommends the following layout for (single-project) repositories (complemented by this question):

/trunk
/tags
  /rel.1 (approximately)
  ...
/branches
  /rel1fixes

What are the relative merits of this arrangement when compared with a (perhaps) more process-oriented one?:

/development
  /current
  /stable
/qa (maybe)
  ...
/production
  /stable
  /Prod.2
  /Prod.1
/vendor
  /Rel.5.1
  /Rel.5.2

Please note that I'm thinking of in-house deployment, rather than building a product.

Disclaimer: although I'm a Subversion user, I've never had to deploy with it in a real live environment.

Answer 1

Whenever you deal with real live environments, you would want your developers to be able to understand your repository as easily as possible. A good way to do this is by adhering to the recommended Subversion standard layout.

Answer 2

The main difference between the recommended layout and your proposed layout is that the recommended layout is somewhat self-documenting as to where to commit things, and how it behaves.

For example, in the recommended layout, it's obvious that all new development is committed to trunk, and most branches are made from trunk. Also, it's obvious that you should never commit anything into /tags. Finally, it's safe to assume that branches are truly branches, which may contain changes specific to that particular branch purpose.

With the proposed layout, some of these things are less certain. Is /development/stable branched from /current? What's the relation between /development/stable and /production/stable? Which of these directories are tags, and which ones can I actually check stuff into?

Certainly this behavior can be documented, but by sticking to the accepted layout that everybody uses, you'll have an easier time getting new hires up to speed on how it works.

Answer 3

I think your plan is pretty good, really. How will you account for branches where a programmer is wandering off on their own just trying something? Maybe like /development/jfm3-messing-around ?

Answer 4

I think flexibility and avoiding ambiguity is your answer.

By using version numbers you do not tie yourself to where that version is deployed.

For example you might have version 1.3 which is deployed as development, 1.2 which is in test and 1.1 which is in production. If you wanted you could easily add another staging environment for another version without having to change your subversion layout.

Nobody can argument what version 1.1 of the code is, but "production-stable" version is ambiguous.

Answer 5

Although I personally use the layout recommended in the SVN book, you probably should not restrict yourself to it if your layout works better for you. I would keep the branch directory since its usage and purpose is pretty clear from the name. Apart from that, really, anything goes if it works for you.

Answer 6

You've described the two pretty much standard models for repository organization: dev-test-prod and trunk-branch. Eric Sink does a nice job of describing them in his Source Control HOWTO. One thing to note is that the way most people use trunk-branch is to create a branch for each version as it is released to customers, which then becomes the maintenance branch.

I would tend to prefer trunk-branch since it doesn't require migrating every single change from development to test to production. Only changes that need to be backported to maintance branches or bugfixes that migrate from the maintance branch to the trunk need to be migrated.

However, one circumstance were dev-test-prod might be preferable is in web development, where the concept of versions released to customers doesn't really exist. Prod, in this case, would be whatever's running on the server right now, while code is being worked on in dev and test and constantly migrated into the application, rather than being released in one big chunk.

Answer 7

I'll try and sum up the answers so far:

---

Simple

1. The "classic" layout (trunk/ + branches/ + tags/) has the advantage of growable simplicity
2. The Trunk is (usually) the main development line
3. Branches attend to special development needs such as complex subprojects and post-release maintenance
4. Tags are fixed, immutable marker posts
5. This classic layout is well-known so your developers get up to speed faster

Expandable

1. Vendor development of products integrated into your development (perhaps with adaptations) can, if required be handled as a vendor branch (normally one is enough)
2. The "Process" axis (Eg. Development, Test if done separately, QA if used, and Production) can be handled by appropriate branch or tag conventions (depending on whether any changes are required or permitted outside "Development").
3. These additional sets of branches can be handled by naming conventions, or by an additional directory level within tags/ or branches/.

See Other Questions

1. What does branch, tag and trunk really mean?
2. What is a good repository layout for releases and projects in Subversion?
3. Do you use the branches-tags-trunk convention?

---

I have made this a community answer; please feel free to correct or extend any deficiencies, for which I apologise.