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.
Background When you hear the words ‘Release notes’, almost always you think of an unsolicited email from a software vendor. But I am here to tell you that from our data, sending release notes via E...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events