How would you organize a Subversion repository for in house software projects?

Question

I work for a company whose primary business is not software related. Most documentation for using source control is written with a development team writing for commercial or

Answer 1

One repository for your projects is probably sufficient. I like the typical approach that indexes the layout by project (see this section from the O'Reilly Subversion book):

/first-project/trunk
/first-project/branches
/first-project/tags
/another-project/trunk
/another-project/branches
/another-project/tags
/common-stuff/trunk
/common-stuff/branches
/common-stuff/tags

Keep in mind that you can always reorganize the repository later.

Also, for in-house stuff, I prefer FSFS for the data-store, as opposed to Berkeley DB. FSFS is more resilient and the speed of checkouts is not much concern for small teams/projects. You can compare and decide for yourself.

Other standard parts of the recipe include Trac and a minimal Linux server to host the repository on the LAN.