Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [git] [platform-ui-dev] How to organize 3.x and 4.x development in Git

Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx> wrote on 08/16/2011 09:11:24 PM:
>
> Yeah, we picked option 1 over option 2 because we didn't want merge
> links from R4_development (master soon, I hope) back to
> R3_development and I won't want anything 4.2 related from
> org.eclipse.ui.workbench to try and be merged back on top of the 3.8
> org.eclipse.ui.workbench (a lot of files have diverged between the 2
> branches for this one plugin).

True, that means the merge is certainly more complicated. I guess you would merge, and then discard all changes made in the forked plugins before pushing the merge commit.

> We also hope to build 4.2 first (from master) and then build 3.8 by
> consuming the 4.2 p2 repo  (the opposite of what we do today) and
> building the plugins that are forked because they're different
> between 3.8 and 4.2 (right now, only org.eclipse.ui.workbench, but
> others might follow).  In that case, it wouldn't even be necessary
> to merge stuff back to R3_development until another bundle is forked
> ... but I'm not clear on what would happen if we let the other
> R3_development bundles atrophy.


The problem with atrophy on R3 for the non-forked plugins is that when committers are doing maintenance work on 3.8 they will checkout the R3 branch, and then have stale code in some plugins. To develop/test their changes would potentially need a mixture of plugins from master and R3 branch. That would require two local clones, with some projects imported into the workspace from one clone, and some from the other. This is pretty convoluted setup for something that will still be relatively common in the near term.

> I think multiple repos will create a move and merge problem, and
> could make history trails very hard to follow.


Yes I agree. A less invasive option suggested to me by Tom Watson is to keep both versions of workbench in the *same* branch under different directories. This would avoid needing multiple branches or multiple repositories, and you can more easily move plugins from the non-split to split sections while maintaining history (I think). The downside is you couldn't easily merge changes across streams for those plugins that aren't split. I don't know how common that case will be (making the same change in both flavours of ui.workbench, for example).

> Maybe we need option one with a cherrypick script for any commits
> that don't touch org.eclipse.ui.workbench?

Andrew is going to investigate a cherry-pick script and report back. That sounds like an interesting direction if it can be done.

John

Back to the top