can crucible track reviews against changesets rather than (repository,changeset)?

[ross andrus]

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"?

[Alexander Taler]

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.

[ross andrus]

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.