Re: [git] [platform-ui-dev] How to organize 3.x and 4.x development in G

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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