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

I agree with using the common conventions of trunk/branches/tags. Beyond that, I think you might be looking for something like my answer at How do you organize your version control repository?.

Answer 2

For subversion, there is Assembla too which comes with Trac and other useful tools. It's free or you could pay for an account if you need more space or users per project.

Answer 3

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.