[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] ptp_6_0 branch created
|
On Fri, Sep 28, 2012 at 3:24 PM, Greg Watson
<g.watson@xxxxxxxxxxxx> wrote:
It sounds like you're advocating for a strategy of committing changes to each branch separately, which is what Chris is suggesting. Is that correct? I'm happy to go that way if you think it provides overall benefits.
No. I still think the current merge strategy is still the best. I only wanted to point out that Chris strategy is not inherently a bad idea, but gives problems if mixed with the current policy.
As far as I see it:
Pro: Current policy / Merge strateg. Cons: Chris / Cherry-pick
- One cannot forget to include bugfixes added to the release branch to master
- The history is clearer because commits have the same commit-ID between branches and only appear once
Cons: Current policy / Merge strateg. Pro: Chris / Cherry-pick
- One doesn't have to undo changes when a patch is only meant for the release branch
- One doesn't get Merge conflicts of other people if they forget to merge
Since patches only for the releaes branch are extremely rare, and the 2nd disadvantage doesn't apply if people merge often enough I think the current policy is better.
But the most important thing (and my focus of my previous) email is that everyone agrees to one policy because otherwise you get all disadvantages and none of the advantages.
@Beth: all projects I know use the current policy and not cherry-pick. Not sure specific for CDT.
Roland
Greg
-----
Linus recently had this to say about Git:
Q
You released the Git distributed version control system less than ten years ago. Git caught on quickly and seems to be the dominant source code control system, or at least the one people argue about most on Reddit and Hacker News.
Linus
Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated
for the black t-shirt crowd.
Q
I thought Subversion was hard to understand. I haven’t wrapped my head around Git yet.
Linus:
You’ll spend a lot of time trying to get your head around it, and being ridiculed by the experts on github and elsewhere. I’ve learned that no toolchain can be too complicated because the drive for prestige and job security is too strong. Eventually you’ll
discover the Easter egg in Git: all meaningful operations can be expressed in terms of the rebase command. Once you figure that out it all makes sense. I thought the joke would be obvious: rebase, freebase, as in what was Linus smoking? But programmers are
an earnest and humorless crowd and the gag was largely lost on them.
On Sep 28, 2012, at 12:09 PM, Roland Schulz wrote:
Hi,
if one always reverts every change in 6.0 in master (either by "merging and then reverting" or by "merging with strategy ours" (later is dangerous if done incorrectly)) for all changes to 6.0 whether or not they should go into master, then it doesn't mess
up things, and also doesn't cause unnecessary merge conflicts. But of course it makes it very inconvient. It still has the problem that it causes double commit messages and unnecessary merge commits in the log. Also it has the disadvantage one can forget to
apply patches from 6.0 to master.
If it is done any other way (without reverting every single commit) one can easily mess up and it can easily happen that patches meant for 6.0 go into master or one gets unnecessary merge conflicts between the patch for 6.0 and the one for master.
These problems wouldn't exist if everyone would apply changes to both branches separately only by mixing merge strategies between members of the same team.
Thus it is highly recommended to use the same merge strategy by everyone of one project.
Roland
On Fri, Sep 28, 2012 at 11:29 AM, Greg Watson
<g.watson@xxxxxxxxxxxx> wrote:
Roland,
Do you know if there is any problem doing it this way?
Greg
On Sep 27, 2012, at 10:46 AM, Chris Recoskie wrote:
I tend to apply my changes manually to both branches rather than merging. Is that workflow going to be a problem?
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
<graycol.gif>Greg Watson ---09/27/2012 10:01:50 AM---Hi, I've created a ptp_6_0 branch for the Juno version of PTP. Kepler builds will now come from the
Hi,
I've created a ptp_6_0 branch for the Juno version of PTP. Kepler builds will now come from the master branch.
Please review the documentation[1] for working on multiple branches, but in summary:
- bug fixes that affect both branches should be committed to the ptp_6_0 branch and then merged with master
- bug fixes that are only for ptp_6_0 branch must be committed to the ptp_6_0 branch and merged with master, then reverse the commit in master
- changes only for master can be committed directly to the master branch
Thanks,
Greg
[1] http://wiki.eclipse.org/PTP/environment_setup/git#Committing_and_Merging
_______________________________________________
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
--
ORNL/UT Center for Molecular Biophysics
cmb.ornl.gov865-241-1537, ORNL PO BOX 2008 MS6309
