Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ptp-dev] Merge policy reminder

Clarification: I wasn't saying the policy wasn't good.
I was saying that the wording on the wiki page was not clear.
Please tell us the steps for what we should be doing when we check in files.

To be honest, I didn't know until last week that we are supposed to "do" a merge when we check files in.
I thought we only had to "do" something if there was a conflict where two people changed the same files.

So please tell me if this is correct.  To change a file we should, if changing both ptp_5_0 and master branches:
1. In ptp50 workspace, commit to ptp_5-0
2. push to put the change on the remote git repository at eclipse.org
3. In ptp60(master) workspace, pull then merge?  merge then pull?  


...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

Inactive hide details for Roland Schulz ---02/10/2012 11:42:33 AM---On Fri, Feb 10, 2012 at 10:34 AM, Beth Tibbitts <tibbitts@uRoland Schulz ---02/10/2012 11:42:33 AM---On Fri, Feb 10, 2012 at 10:34 AM, Beth Tibbitts <tibbitts@xxxxxxxxxx> wrote: >  I think the procedur


    From:

Roland Schulz <roland@xxxxxxx>

    To:

Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>,

    Date:

02/10/2012 11:42 AM

    Subject:

Re: [ptp-dev] Merge policy reminder

    Sent by:

ptp-dev-bounces@xxxxxxxxxxx





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_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev


GIF image

GIF image

Back to the top