Crucible and Perforce - single repository, or many?

We are running Crucible 2.8.1 and have configured it with our Perforce 2010.1 server. In our Perforce repository, we have many dozens of active branches that contain changes that we'd like to be able to review with Crucible across different Crucible projects. I'm not sure from the documentation whether I should configure a single repository in Crucible that points to everything (//depot/...), or if I should make several smaller repositories (//depot/eng/iOS/feature/featureA, //depot/eng/Android/feature/featureB, etc).

Using smaller repositories is tedious, because someone has to come in and create a new repository each time we create a new source code branch in Perforce (//depot/eng/server/feature/featureA). With several dozen new projects, that becomes messy and high-maintenance.

Using a single large repository covers everything. But I wonder if this is frowned upon for efficiency? What is the recommendation here? We are not using Fisheye, so I presume it's using build-in 'light' Fisheye.

Thanks very much for your help!

2 answers

0 vote
Janet Albion Atlassian Team Mar 14, 2013

Hi Jeff,

In case if you haven't review the Exclude path feature in FishEye especially for large , you might to check this feature. Detail on performance tuning available at:

https://confluence.atlassian.com/display/FISHEYE/Tuning+FishEye+performance

0 vote

Hi Jeff,

We recommend splitting large repositories into smaller logical components (i.e., by product or project):

https://confluence.atlassian.com/display/FISHEYE/Best+practices+for+FishEye+configuration

The advantages of doing that, according to the link above, are:

  • A logical structure will make it simpler to exclude certain branches when they become less relevant to work in progress. This can garner significant performance gains.
  • Avoid treating an SCM like a file system — don't alter the structure or move items around without a significant reason for doing so. Make these changes sparingly and as infrequently as possible.
  • The more often you make major changes to the structure inside your SCM, the more scanning is required for FishEye to keep track of its status. This especially applies to Subversion, because of its concept of 'cheap copies'. The result is that small changes can be essentially unmeasurable and cause a large amount of re-scanning.

There's no need to create a separate repository for each branch.

If this answer was helpful, please allow me to ask you to mark my answer as accepted in order to have it in the top of the thread, also helping other customers.

Thanks in advance!

Kind regards,
Felipe Kraemer
Atlassian Support

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda&nbsp...

1,764 views 1 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you