--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "reviewboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Radek,This is really a lot more work than it seems like it'll be.Diff files themselves have no concept of a repository they're associated with. We do have a repository reference for DiffSet model entries, but you're not going to squeeze multiple concurrent DiffSets onto a review request. We'd need a lot of work on the schema, the UI, and the API to make all this work, and it's a huge project that will leave you unable to cleanly upgrade in the future.There may be another approach, which is to create a sort of "proxy" hosting service that wraps your other repositories. So basically, one repository pretending to be multiple ones. The problem then has to do with file lookups. You'd need a custom diffs generated by custom tools that, for instance, prefixes file paths with a repository identifier, so the hosting service can know where to look up the files. For instance, a diff containing /repo123/absolute/path/to/file could be handled by the hosting service by stripping off that first bit, looking up the correct backing repository, and then passing the rest of the path to it.That's probably the least-invasive way of handling this. The client-side tooling might be the biggest part of this.Christian
On Fri, Jan 18, 2019 at 8:04 AM rchmielarz <radoslaw...@gmail.com> wrote:
--Hi all,I'm also interested in this feature since the group I'm working with uses git submodules and we are interested in a coherent review. But since there was no interest from review board developers so far I wanted to ask: where should I start to implement a proof of concept for git? I'm interested only to extend it for patches.A single review can have only one associated repository in the sql schema it seems, this can probably be easily changed. But then I would have to create a special format of patches so that each file is attributed to a repository so that the review board could show the differences. Is such a patch format already available by some tools? And let's say I manage all that: review has multiple repositories and I have a patch which has them associacted with each of those repositories. Is there anything else that should be taken care of?Cheers,Radek
On Thursday, 23 November 2017 20:15:14 UTC+1, Eric Chamberland wrote:Hi,I just jump into this conversation to say that we have the same problem here: we have to manage a "review" as a set of changes across multiple repositories.So +1 for this feature to be implemented.Thanks,Eric
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to revie...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
how about having reviews follow the epic/story model... a parent review with child reviews. Each child review would be associated with individual repositories, and you then set it so that nothing can be landed until all related reviews are marked as ship-its?this might be much easier to achieve in the reviewboard code than reviews which span repositories?
--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAMukpcDcj2EWW%2Bv6JdFo57OcxtBuFpk1mr4YQH0mJz5vsQe%3DtQ%40mail.gmail.com.