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.
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.