Re: [ptp-dev] Merge policy reminder

[Roland Schulz <roland@xxxxxxx>]

On Fri, Feb 10, 2012 at 10:34 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote:

I think the procedure on the wiki needs to clearly state thie in http://wiki.eclipse.org/PTP/environment_setup/git#Merging
It says "all changes in ptp_5_0 are regularly merged into master"   It sounds like this might happen automatically - I'll admit I didn't understand this until recently.

I wrote this because this is how I am used to doing merges on my other projects (and main other project "Gromacs" has similar number of code-lines, commits and contributors). And this always worked fine. Not automatically but without little problem for the person doing the merge. 

Is the merge difficult for PTP?

Greg, do you have some rough estimate of how often you get merge conflicts when doing a merge? And if this number is high, is there some dominant reason for those conflicts? I'm asking because doing the merge for Gromacs is often conflict free or the conflicts are very easy to resolve even for the person who didn't write the code.

I just looked at the log and I could only find two merges which had conflicts. If that is true I don't understand the problem. That would mean that for the large majority of merges, git was able to do the merge automatically without the need to resolve any conflict (after someone told git to do the merge). And if that is true I don't understand Greg's originally message.

On the other hand if the log is not correct and there were many merges which had conflicts it would be good to know why the log is incorrect. Also it would be important to make sure that the messages are correct in the future because I think a SCM system with incorrect log is not good at all.

If we state the procedure clearly on the wiki as the steps to take when you check in something, then it's easier for people to learn how to do.

I can make the steps say
To check into 50 and master:  (Two diff workspaces assumed)
1. check in: commit and push to ptp_5_0
   2. from master: what order of Team>Merge and Team>Pull??

you want to first pull (or fetch). Because if you don't have the remote tracking branch updated you won't merge in the changes you have done in the different work space.

 

BTW: I just realized another problem with Egit: For the merge one has to have all the projects, which have a conflict, opened in the workspace (otherwise one can't resolve the conflict within Eclipse). Thus it is probably best if one has them all and all open.

 

...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform  http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511

Greg Watson ---02/10/2012 10:16:56 AM---Hence my original message reminding people that they need to merge their changes. The scenario outli

From:	Greg Watson <g.watson@xxxxxxxxxxxx>
To:	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>,
Date:	02/10/2012 10:16 AM
Subject:	Re: [ptp-dev] Merge policy reminder
Sent by:	ptp-dev-bounces@xxxxxxxxxxx

---

Hence my original message reminding people that they need to merge their changes. The scenario outlined below is only the case if changes have not been merged.

Typically what happens (to me) is that I commit something to ptp_5_0, then go to merge with master. At that point I find that someone has committed something to ptp_5_0 but not merged. Git does not allow selective merging, so I can either merge everything or nothing.

The only options I see are:

1. Merge everything, and notify the list that there were some un-merged commits. This has the advantage of not interrupting workflow, but could result in merge problems. It's also problematic if there are conflicts in the un-merged commits.

2. Merge nothing, and notify the list that there were some un-merged commits. The owner of the commits would then need to merge these before the merge could proceed. This is problematic if the owner is in another timezone, or on vacation, or whatever, since the merge is blocked at this point.

What do people want to do in this situation?

Greg

On Feb 10, 2012, at 9:32 AM, Jeffrey Overbey wrote:

If you find that someone else has made a change without merging it, then you have no choice but to do the merge yourself and assume that it is ok.

With all due respect, I really don't like this.  It totally disregards code ownership, it adds an unnecessary burden to the merge procedure, and it's absolutely asking for bugs caused by people modifying code they didn't write and don't fully understand.

If the technical limitations of our merge procedure are forcing us to make bad policy decisions, then there's something wrong with our merge procedure.

(Sorry, I don't have a solution, just an opinion...)


Jeff
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

-- 
ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309