Project in crucible refers to whatever you want it to refer to. This is the grouping under which reviews occur. It is primarily used to configure things like permissions, who can access, review etc. Though the applications run together under the same server config they really are two separate apps that reference each other.
It sounds to me as though you're over thinking this a bit (Something I am guilty of frequently). Fisheye and Crucible both point to paths in SVN, nothing more than that. There isn't any magic going on here. Symbolic links or physical paths should resolve to the same thing. Just a location on the filesystem when the repository path (designated by your configuration) is accessed.
I would expect your example: https: to show the tree for the three Subfolders listed above A B and common.
If you wanted to get more granular in your fisheye and in your crucible configure them down to the A, B, and Common folder above. (Yes, enter all three under three configurations). That is what I would probably do.
This might make more sense since your branches/tags/trunks folders refer to that level.
Otherwise I don't think Fisheye will be able to do a good job of displaying branches because you're referencing too close to the root in the tree. If you're supporting multiple branches of development concurrently this will become important. It will allow you to use the commit graph with your branches. This is perhaps the most inspired tool in the Fisheye arsenal.
Fisheye will display whatever you configure. So if you define a repository location of Common you can configure it with a root path of https: then your branches, tags, and trunk folder will behave as expected. In that case I'd leave the "module" field blank in Fisheye repo config. (I think this is right, you may need to back off to HWSpecificCode in your repo url and use Common as your module. play with it, no harm no foul if you change it. Just reindexing which can take a while.)
Now, if you have occasion to want to see them all in the same view you can configure a fourth repository that accesses all three folders (A, B, Common) together in the same view by configuring it as you have it now. This could be handy for certain things, but you'll be hitting each folder more than once in the indexing so there will likely be a performance hit.
The reason why it is important to configure with your branches/tags/trunk at the level I describe above is that when you tag, or branch, you are doing so at that level in the repository, not at the https: level which you have described above.
Hope this helps. (it's not really as complicated as it seems, but I know how confusing this can be when you're first getting started).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.