One repository or many?

Julian Green (KMIS)

I know that there is no absolute answer to this question but our Perforce repository structure is:-

//common/...
//clients/client1/...
//clients/client2/...
//clients/client3/... etc.

In JIRA we have one project per client. Each project connects to the common repository and a single client repository.

What are the advantages/disadvantages of:
a) Having a minimal fisheye repository
ie have 2 repositories in fisheye (//common/... and //clients/...) and connecting all JIRA projects to both
and defining a repository path (of /clientx) for each client.
Would defining the project repository path in jira inpact the reporting of changes to /common/...?

or

b) Having a more comlex repsitory structure in fisheye
ie defining separate repositories for each client (//clients/client1/... , //clients/client2/... etc)
in this case the JIRA cnfiguration is simplified as there is no need to specify a path for each project.

There seems to be a trade-off between a complex setup for FishEya and simple one for JIRA and vice verse.

I am not asking which is better for me, that has to be my decision, but I am not clear about the impact (advantages/disadvantages) of these options.

Norman Abramovitz

I may be wrong here because I am still evaluating Fisheye, but I preceive FishEye like a virtualized source control system. So you can get a consistent view across multiple source control respositories. FishEye also seems to provide a more integrated feel with Jira in comparison to the subversion plugin as an example.

So I would based my decision based upon security issues verses the administrator ease of use. For example, can everyone see the repository changes?

From what I can tell your end user experience would be the same in either scheme. So if the simplier design works, I would suggest going with it.