[
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
|
On Tue, Aug 16, 2011 at 1:37 PM, John Arthorne
<John_Arthorne@xxxxxxxxxx> wrote:
Problem:
Eclipse Platform UI has roughly 40 plugins
in a single Git repository. Two of those plugins have code differences
between the 3.x and 4.x streams. Since branches in Git operate at the granularity
of a whole repository, it means 38 plugins need to maintain identical contents
in those two branches. In CVS this problem was easy because individual
folders in the repository could be forked independently. The question is,
how do we organize our development in a way that minimizes pain for committers
and avoids too many manual steps prone to user error.
Possible Solutions:
1. Do all development in master (4.x),
and then cherry-pick each commit over to the 3.x branch. Commits that involve
both split and non-split bundles would need to be merged manually. This
is what the team is doing today. It works, but there is a chance committers
will forget to merge every change across to 3.x, and it adds extra overhead
for committers every time they make any code change (make change, run tests,
commit to master, push, checkout 3.x, find and cherry-pick the commit,
test, push to 3.x, checkout master again).
2. Do all development in master (4.x),
and once a week rebase the 3.x branch to pick up all the changes made in
master (perhaps a single person does this as part of 3.8 build submission
procedure). This avoids the overhead for each commit, but has a once a
week pain of performing that rebase and manually merging any conflicts.
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).
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.
I think multiple repos will create a move and merge problem, and could make history trails very hard to follow.
Maybe we need option one with a cherrypick script for any commits that don't touch org.eclipse.ui.workbench?
Later,
PW
--
Paul Webster
Hi floor. Make me a sammich! - GIR
