Presently, we’ve got several main projects each in their own repository. We will have to version-control up to a dozen additional projects. VisualSVN recommends to create 1 respository for our company and then vc all projects inside that.
It’s a good practice to create one repository for the entire company or department and store all your projects in this repository. Creating separate repository for each project is not a good idea because in that case you will not be able to perform Subversion operations like copy, diff and merge cross-project. VisualSvn.com
Currently we’re using post-commit hooks to update the testing server with the latest commit and do other project specific actions (such as emailing certain people for one project but not for others) depending on which project has been committed.
As post-commit runs for the whole repository, is this still possible in such a situation? How would I go about decerning which project has changes? filter folder structure?
I’m not sure I would agree with that VisualSVN recommendation. I have always set up separate repositories per project, and I’ve never run into a situation where I wish I could have merged across projects or something.
If there is a chunk of common code that is shared among projects at your company, it should become a shared library project of its own (with its own repository, too).