Fwd: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge - Changes to accomodate.
The below changes were from Alexander Belopolsky. When I tried to push my changes, my changes resulted in multiple heads in 2.7, so I had to go back 2.7 branch, merge 2.7 and then commit and push. This resulted in both my changes as well as merged changes being pushed. I understand that the second part should not happen, like merging an already available change and then pushing it again. I have a script which kind of traverses all the local directories of branches and does a hg pull; hg update before I start making changes and I thought that was enough. How could the push would resulted in two heads here and why I did have merge ? ( I am unable to traceback the steps) and if there is anything I should know, or change in the workflow when doing changes to 2.7, please let me know. Thanks, Senthil ---------- Forwarded message ---------- From: senthil.kumaran <python-checkins@python.org> Date: Wed, Apr 6, 2011 at 2:45 PM Subject: [Python-checkins] cpython (merge 2.7 -> 2.7): hg pull/merge - Changes to accomodate. To: python-checkins@python.org http://hg.python.org/cpython/rev/da212fa62fea changeset: 69170:da212fa62fea branch: 2.7 parent: 69169:1320f29bcf98 parent: 69165:202a9feb1fd6 user: Senthil Kumaran <orsenthil@gmail.com> date: Wed Apr 06 14:41:42 2011 +0800 summary: hg pull/merge - Changes to accomodate. files: Lib/test/test_datetime.py | 7 +++++++ Modules/datetimemodule.c | 15 ++++++++------- 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/Lib/test/test_datetime.py b/Lib/test/test_datetime.py --- a/Lib/test/test_datetime.py +++ b/Lib/test/test_datetime.py @@ -231,6 +231,13 @@ eq(a//10, td(0, 7*24*360)) eq(a//3600000, td(0, 0, 7*24*1000)) + # Issue #11576 + eq(td(999999999, 86399, 999999) - td(999999999, 86399, 999998), + td(0, 0, 1)) + eq(td(999999999, 1, 1) - td(999999999, 1, 0), + td(0, 0, 1)) + + def test_disallowed_computations(self): a = timedelta(42) diff --git a/Modules/datetimemodule.c b/Modules/datetimemodule.c --- a/Modules/datetimemodule.c +++ b/Modules/datetimemodule.c @@ -1737,13 +1737,14 @@ if (PyDelta_Check(left) && PyDelta_Check(right)) { /* delta - delta */ - PyObject *minus_right = PyNumber_Negative(right); - if (minus_right) { - result = delta_add(left, minus_right); - Py_DECREF(minus_right); - } - else - result = NULL; + /* The C-level additions can't overflow because of the + * invariant bounds. + */ + int days = GET_TD_DAYS(left) - GET_TD_DAYS(right); + int seconds = GET_TD_SECONDS(left) - GET_TD_SECONDS(right); + int microseconds = GET_TD_MICROSECONDS(left) - + GET_TD_MICROSECONDS(right); + result = new_delta(days, seconds, microseconds, 1); } if (result == Py_NotImplemented) -- Repository URL: http://hg.python.org/cpython _______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins -- Senthil
Le mercredi 06 avril 2011 à 15:07 +0800, Senthil Kumaran a écrit :
The below changes were from Alexander Belopolsky. When I tried to push my changes, my changes resulted in multiple heads in 2.7, so I had to go back 2.7 branch, merge 2.7 and then commit and push. This resulted in both my changes as well as merged changes being pushed.
Well, this is normal. Do understand that history with a DVCS is not linear. You have based your changes on an earlier revision (for whatever reason - for example someone pushed a new revision in-between), and so you had to merge - reconcile - your changes with the latest upstream changes. This is normal practice.
I guess you have been surprised by the diff in the notification e-mail, which makes it look like that the datetime changes have been committed "twice". The diff displays the differences between the merge changeset and one of its parents (the first one, probably). So, it will reflect the changes made necessary to one of its two parents in order to reconcile it with the other; it "appears" (due to the diff) that some changes have been committed twice, but it's only so if you consider history linear as in SVN.
I think the representation of merges as a diff against one of the parents is indeed sub-optimal. OTOH, it's not easy to come up with something better.
I have a script which kind of traverses all the local directories of branches and does a hg pull; hg update before I start making changes and I thought that was enough.
It should be enough, but perhaps other changes were pushed in-between.
Regards
Antoine.
On Wed, Apr 6, 2011 at 16:08, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think the representation of merges as a diff against one of the parents is indeed sub-optimal. OTOH, it's not easy to come up with something better.
This might be of interest: https://bitbucket.org/wolever/hg-mergediff/.
Cheers,
Dirkjan
On 06/04/2011 17.08, Antoine Pitrou wrote:
The below changes were from Alexander Belopolsky. When I tried to push my changes, my changes resulted in multiple heads in 2.7, so I had to go back 2.7 branch, merge 2.7 and then commit and push. This resulted in both my changes as well as merged changes being pushed. Well, this is normal. Do understand that history with a DVCS is not
Le mercredi 06 avril 2011 à 15:07 +0800, Senthil Kumaran a écrit : linear. You have based your changes on an earlier revision (for whatever reason - for example someone pushed a new revision in-between), and so you had to merge - reconcile - your changes with the latest upstream changes. This is normal practice.
I guess you have been surprised by the diff in the notification e-mail, which makes it look like that the datetime changes have been committed "twice". The diff displays the differences between the merge changeset and one of its parents (the first one, probably). So, it will reflect the changes made necessary to one of its two parents in order to reconcile it with the other; it "appears" (due to the diff) that some changes have been committed twice, but it's only so if you consider history linear as in SVN.
I think the representation of merges as a diff against one of the parents is indeed sub-optimal. OTOH, it's not easy to come up with something better.
FWIW I've been trying to tweak the mail hook to show only the chunks
that are actually changing something on hg.python.org (h.p.o).
In a merge on the same branch (e.g. 2.7 -> 2.7), the diff in the mail
shows the pulled changes. So if Senthil commits something, pulls
Alexander changes and merges, the diff will show Alexander changes.
That's correct from Senthil repo's point of view. The problem is that
the mail hook does the same and shows us Alexander changes again instead
of making a new diff from h.p.o points of view.
Technically same-branch merges could be ignored, because we already got mails for both the parents (i.e. Senthil and Alexander changes). Who makes the merge might change something in the meanwhile though, so we want to extract these extra changes from the merge to see and review them. This turned out to be quite complicated, and I couldn't find any approach that works reliably in all the cases.
The easiest solution I found to see only what changed on h.p.o is to use a changegroup hook instead of an incoming hook, in order to get all the commits at once (when a committer pushes) and make a single diff. The "whole diff" mail could be sent only when the push includes a same-branch merge (in addition or instead the per-commit ones), and have the same per-commit mails when there are no same-branch merges.
Another way to find changes is to make crossed checks, but that doesn't work too well in complex cases. This means:
/-> A -
-P M
\-> S -/
(P=parent, A=Alexander, S=Senthil, M=merge)
Assume that Alexander committed his change in A and Senthil committed his change in S, then:
- the diff from A and M should be equal to the diff from P and S, and
- the diff from S and M should be equal to the diff from P and A. If both the diffs are not equal, something else changed.
This is similar to the algorithm used b the MergediffExtension, and can be extended to work in this case too:
/-> A1 -> A2 -> A3 -
-P M
\-> S1 -> S2 -> S3 -/
but if the case is like this it starts to get complicated:
/-> A1 -> A2 -> A3 -> A4 -
-P \ M1
\---> S1 --> M0 --> S2 ---/
(i.e. Senthil does some changes (S1), pulls and merges what Alexander pushed on h.p.o (A1/A2), does more changes (S2), pulls and merges another set of changes pushed by Alexander (A3/A4) -- this might be common with long-term feature branches.)
I'm not sure the mergediff extension can handle all this cases and, even if it can, we need to adapt it to be used from the mail hook.
Best Regards, Ezio Melotti
I have a script which kind of traverses all the local directories of branches and does a hg pull; hg update before I start making changes and I thought that was enough. It should be enough, but perhaps other changes were pushed in-between.
Regards
Antoine.
On 4/6/2011 4:45 PM, Ezio Melotti wrote:
On 06/04/2011 17.08, Antoine Pitrou wrote:
The below changes were from Alexander Belopolsky. When I tried to push my changes, my changes resulted in multiple heads in 2.7, so I had to go back 2.7 branch, merge 2.7 and then commit and push. This resulted in both my changes as well as merged changes being pushed. Well, this is normal. Do understand that history with a DVCS is not
Le mercredi 06 avril 2011 à 15:07 +0800, Senthil Kumaran a écrit : linear. You have based your changes on an earlier revision (for whatever reason - for example someone pushed a new revision in-between), and so you had to merge - reconcile - your changes with the latest upstream changes. This is normal practice.
I guess you have been surprised by the diff in the notification e-mail, which makes it look like that the datetime changes have been committed "twice". The diff displays the differences between the merge changeset and one of its parents (the first one, probably). So, it will reflect the changes made necessary to one of its two parents in order to reconcile it with the other; it "appears" (due to the diff) that some changes have been committed twice, but it's only so if you consider history linear as in SVN.
I think the representation of merges as a diff against one of the parents is indeed sub-optimal. OTOH, it's not easy to come up with something better.
FWIW I've been trying to tweak the mail hook to show only the chunks that are actually changing something on hg.python.org (h.p.o). In a merge on the same branch (e.g. 2.7 -> 2.7), the diff in the mail shows the pulled changes. So if Senthil commits something, pulls Alexander changes and merges, the diff will show Alexander changes. That's correct from Senthil repo's point of view. The problem is that the mail hook does the same and shows us Alexander changes again instead of making a new diff from h.p.o points of view.
Technically same-branch merges could be ignored, because we already got mails for both the parents (i.e. Senthil and Alexander changes). Who makes the merge might change something in the meanwhile though, so we want to extract these extra changes from the merge to see and review them. This turned out to be quite complicated, and I couldn't find any approach that works reliably in all the cases.
The easiest solution I found to see only what changed on h.p.o is to use a changegroup hook instead of an incoming hook, in order to get all the commits at once (when a committer pushes) and make a single diff. The "whole diff" mail could be sent only when the push includes a same-branch merge (in addition or instead the per-commit ones), and have the same per-commit mails when there are no same-branch merges.
Another way to find changes is to make crossed checks, but that doesn't work too well in complex cases. This means:
/-> A -
-P M \-> S -/(P=parent, A=Alexander, S=Senthil, M=merge)
Assume that Alexander committed his change in A and Senthil committed his change in S, then:
- the diff from A and M should be equal to the diff from P and S, and
- the diff from S and M should be equal to the diff from P and A. If both the diffs are not equal, something else changed.
Like Senthil, I have been puzzled by the duplicate diffs. think it might help other hg newcomers if something like the above were in the dev docs.
This is similar to the algorithm used b the MergediffExtension, and can be extended to work in this case too:
/-> A1 -> A2 -> A3 -
-P M \-> S1 -> S2 -> S3 -/but if the case is like this it starts to get complicated:
/-> A1 -> A2 -> A3 -> A4 -
-P \ M1 \---> S1 --> M0 --> S2 ---/(i.e. Senthil does some changes (S1), pulls and merges what Alexander pushed on h.p.o (A1/A2), does more changes (S2), pulls and merges another set of changes pushed by Alexander (A3/A4) -- this might be common with long-term feature branches.)
Terry
participants (5)
-
Antoine Pitrou -
Dirkjan Ochtman -
Ezio Melotti -
Senthil Kumaran -
Terry Reedy