[cross posting to Reviews and cross-project list] We've got an interesting issue with reviews that span git repositories. In this case we are likely to have many reviews such as this that involve very large refactorings that only make sense and work as a whole, and the last thing we want is a workflow that puts us into git/gerrit merge hell. Given the issues involved, it almost seems like it would be easier to merge the repos.. ;P
I'm wondering if any other projects have run into this issue and whether people have ideas for a relatively manageable way to handle this? On 2012-09-18, at 6:38 PM, Steffen Pingel <[email protected]> wrote: > In terms of automated validation of changes, I don't see a straight forward > way to make that work. We will need to rely on merging framework changes > first and then retrigger validation for R4E to consume those changes. Gerrit > does have a notion of topics for related changes but I am not sure that the > Eclipse.org Gerrit already has that support and how you could integrate it > with the Gerrit trigger job. > > Steffen > > > On Tue, Sep 18, 2012 at 5:54 PM, Miles Parker <[email protected]> > wrote: > > An additional bit of real awkwardness I just discovered that hadn't occurred > to me until I just went to commit a proposed change to the Reviews model(s): > > Many of the refactorings will span both repos. In fact, all of the really > interesting one's probably will! How the heck will be manage that with > Gerrit, given that we will have to have two separate reviews for each change > and there isn't anyway to synchronize them?! _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
