We use mercurial, and our process frequently entails making clones of repositories for special work. We enlist all of these in crucible, so that for some respo "foo" we have "foo_common", "foo_project1", "foo_project2".
Crucible sees them as separate entities, and when I review (foo_project1,changeset123), and when we merge back to foo_common, the review for changeset123 doesn't follow.
That is, when I look at that changeset in the context of foo_project1 I can see it's assocaited to review CR123, but when I look at the same changeset back in the "foo" crucible enlistment, there's no mention that it was reviewed.
This is especially irksome as I'd like to use e.g. Flyover to assay review coverage.
What I'd like is for some way to get crucible to understand that the repositories are really the same repository and that a review of changeset123 in one repository is a review in all repositories.
I'm prepared to believe I'm thinking about this wrong, but I can't believe I'm the only one. I've tried searching the knowledge base, and google, but no satisfaction.
Any suggestions aside from "one repository to rule them all"?
Crucible has to work like this, by default at least, because Subversion revision ids are not unique across repositories, they are just a numerical sequence.
If you can configure a single repository, and multiple branches within that repository, then you can attach multiple projects to it, and Flyover would recognise reviews as you want. This is going to depend on how you're using Mercurial of course.
Flyover could be modified to support your scenario if you'd like to discuss further.
Thanks for the reply.
I understand the rationale, but mercurial and git are pretty popular and both have a stable notion of changeset identitiy across repository clones, so I was hoping there might be some (obscure) way to leverage the distinction between "identity" and "location".
Yes, branching withing a single repo will work - it's what I meant by the "one repository to rule them all" approach - but it doesn't fit our workflow, so it's not really an option.
Everything below is tested on Ubuntu 17.10. I prefer to use Jira in a docker container because: 1. I can install Jira with a couple of commands. 2. I can start and stop Jira just by starting and s...
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!
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot