Reputation: 1720
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?
Upvotes: 3
Views: 621
Reputation: 47356
From the post-commit
hook, run the svnlook changed
command to find out which paths are affected by a commit. You could use a grep
to see if they include some project path.
Upvotes: 1
Reputation: 994051
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).
Upvotes: 0
Reputation: 4755
You can check the paths of the commited files to determine which project they belongs to. Just remember that a commit can modify several files at once, and each file could theoretically belong to a different project.
Upvotes: 1