On 06/04/2011 17.08, Antoine Pitrou wrote:
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.
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.
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
