Re: [git] How to organize 3.x and 4.x development in Git

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

You're right of course. Since these are
commits that are already out on the remote server we would need to merge
rather than rebase. Thanks Steffen.

John

Steffen Pingel <steffen.pingel@xxxxxxxxxxx>
Sent by: git-bounces@xxxxxxxxxxx

08/16/2011 02:36 PM

Please respond to
"Git related discussions,        specifcally migration help for projects at Eclipse.org"        <git@xxxxxxxxxxx>

To	"Git related discussions,        specifcally migration help for projects at Eclipse.org" <git@xxxxxxxxxxx>
cc
Subject	Re: [git] How to organize 3.x and 4.x development in Git

For Mylyn we had to branch one of our repositories as
well to maintain separate streams for two bundles. We are doing something
similar to (2) but instead of rebasing I run "git merge origin/master"
before integration builds to update the branch. So far overhead has been
low but admittedly differences between streams are minimal so
far so merging hasn't caused any conflicts, yet.

While rebasing avoids merge commits it has more potential
for conflicts since each incremental change is re-applied each time. It
will also change commits in the branch which causes problems for anyone
who has cloned the repository and based work of those commits.

Steffen


On Tue, Aug 16, 2011 at 7: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. 

3. Maintain two separate Git repositories - one for the two split plugins,
and one for the 38 plugins that are not split. This mimics the setup we
had in CVS and avoids any extra pain on developers for maintaining two
branches for things that don't actually need to be branched. The big downside
is that if we later decide to split more plugins (quite likely), they would
need to be transferred over to the "split plugins" repository.
Moving subtrees across git repositories while maintaining all their commit
history is a painful operation. Over the long term, splitting repositories
along the lines of what is forked and what isn't is going to be a headache.

4. Do all development in master (4.x), and don't bother porting back to
3.8 stream unless it is a critical bug (treat 3.8 purely as critical maintenance).

Are there any other suggestions for how to organize development in this
scenario? Are there other advantages/disadvantages to the above solutions
that I am forgetting? What is the current preference among Platform UI
committers? 

Separate from how we actually do the development, I was thinking it would
be useful to have a verification script that checks out master and 3.x
streams and verifies that the 38 non-split plugins are identical. This
could at least help catch any cases of user error that could come up with
1. and 2. If there are existing tools out there to do that in Git, please
chime in. 

john 


_______________________________________________
git mailing list
git@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/git




-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com_______________________________________________
git mailing list
git@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/git