Projects per repository

schweeneh · Post by **schweeneh** » Thu Jul 17, 2008 12:34 pm

I've read the best practices on how to set up a repository. It was helpful but I'm still a little uncertain about exactly how big is too big and what the best practices are for managing repostitories.

My first thought was to create a separate repostitory for every project, but then I realized I needed to create shared folders between them and I can't do that between repositories.

My question really is, how big does a repository have to be before I start seeing these 5 minute login times and 20 minute branching operations that I've read about?

also, is it normal to put 10, 20, 30 or more projects in the same repository?

if so, doesn't the repository get incredibly bloated with branches of every version of every project, plus separate experimental developent branches plus dev,test,prod branches?

A reponse from someone with experience with this would be greatly appreciated.

Thanks in advance.

-Chris

lbauer · Post by **lbauer** » Thu Jul 17, 2008 2:29 pm

My question really is, how big does a repository have to be before I start seeing these 5 minute login times and 20 minute branching operations that I've read about?

The short answer: It depends.

We've made improvement in performance in Vault 4.1 and Vault 4.1.3 will further improve branching time. So if you're on the latest version you should get good performance. If not, we want to hear about it and fix the slowdown.

If you're on an older version, upgrade. There were various performance bottlenecks in previous versions.

That being said, if you have a large database and many thousands of nodes in the repository tree, you need adequate system resources -- fast disk drives, CPU and enough memory. Performance for one huge repository will not be as good as for serveral smaller ones.

If you can divide up projects into separate repositories, do so. But if you can't because you need to share, etc. then keep them in one. You can always delete branches from the tree to improve performance (they don't have to be obliterated, just deleted, and you can undelete them if you need them again).

Do regular database maintenance, defrag your disk drives, and contact us if you have unusual slowdowns.

schweeneh · Post by **schweeneh** » Thu Jul 17, 2008 4:09 pm

We're on 4.0.6 and intend to upgrade to 4.1.3 when it's released.

Thank you for your answer, it was very helpful.

- Chris

lbauer · Post by **lbauer** » Fri Jul 18, 2008 2:05 pm

You're welcome.