Re: [Python-Dev] Merging 3.2 to 3.3 is messy because "Misc/NEWS"

2011-11-27 Thread Petri Lehtinen
Jesus Cea wrote:
> On 12/11/11 16:56, Éric Araujo wrote:
> > Ezio and I chatted a bit about his on IRC and he may try to write
> > a Python parser for Misc/NEWS in order to write a fully automated
> > merge tool.
> 
> Anything new in this front? :-)

I don't see what's the problem really. The most common case is to have
one conflicting file with one conflict. I'm completely fine with
removing the conflict markers and possibly moving my own entry above
the other entries.

Petri
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Long term development external named branches and periodic merges from python

2011-11-27 Thread Jesus Cea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/11/11 17:30, Éric Araujo wrote:
>> That is what I want to do, but I need to know that it is safe to
>> do so (from the "Create Patch" perspective).
> I don’t understand “safe”.

"Safe", in this context, means "when clicking 'create patch' the
created patch ONLY includes my code in the development branch, EVEN if
the branch merged-in the original mainline branch several times".

 6. What would be posted in the bug tracker when she does a
 new "Create Patch"?. Only her changes, her changes SINCE the
 merge, her changes plus merged changes or something else?.
>>> The diff would be equivalent to “hg diff -r base” and would
>>> contain all the changes she did to add the bug fix or feature.
>>> Merging only makes sure that the computed diff does not appear
>>> to touch unrelated files, IOW that it applies cleanly.
>>> (Barring bugs in Mercurial-Roundup integration, we have a few
>>> of these in the metatracker.)
>> So you are saying that "Create patch" will ONLY get the
>> differences in the development branch and not the changes brought
>> in from the merge?.
> I don’t really understand how you understood what I said :(  The
> merge brings in changes from default; when you diff your branch
> against default later, it will not show the changes brought by the
> merge, but it will apply cleanly on top of default.

But I am not doing that diff, it is the tracker who is doing that diff.

I agree that the following procedure would work. In fact it is the way
I used to work, before publishing my repository and using "create
patch" in the tracker:

1. Branch.
2. Develop in the branch.
3. Merge changes from mainline INTO the branch.
4. Jump to 2 as many times as needed.
5. When done:
   5.1. Do a final merge from mainline to branch.
   5.2. Do a DIFF from branch to mainline.

After 5.2, the diff shows only the code I have patched in the branch.
PERFECT.

But I don't know if the tracker does that or not. Without the final
merge, a diff between my branch and mainline tips will show my changes
PLUS the "undoing" of any change in mainline that I didn't merge in my
branch.

Since "create patch" (in the tracker) doesn't compare against the tip
of mainline (at least not in a trivial way), I guess it is comparing
against the BASE of the branch. That is ok... as far as I don't merge
changes from mainline to the branch. If so, when diffing the branch
tip from the branch base it will show all changes in the branch, both
my code and the code imported via merges.

So, in this context, if the tracker "create patch" diff from BASE, it
is not "safe" to merge changes from mainline to the branch, because if
so "create patch" would include code not related to my work.

I could try actually merging and clicking "create patch" but if the
result is unpleasant my repository would be in a state "not
compatible" with "create patch" tool in the tracker. I rather prefer
to avoid that, if somebody knows the answer. If nobody can tell,
experimentation would be the only option, although any experimental
result would be suspicious because the hooks can be changes later or
you are hitting any strange corner case.

Another approach, that I am doing so far, is to avoid merging from
mainline while developing in a branch, just in case. But I am hitting
now a situation while there are changes in mainline that overlap my
effort so I am quite forced to merge that code in, instead of dealing
with a huge divergent code in a month.

So, I have avoid to merge in the past and was happy, but I would need
to merge now (changes from mainline) and I am unsure on what is going
to happen with the "create patch" option in the tracker.

Anybody knows the mercurial command used to implement "create patch"?.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[email protected] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[email protected] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTtMMPplgi5GaxT1NAQKzhQP8DzAql1PAJkyEROsWl8CgPpW9ie8jNM1V
+K5jLx/dCukzFXrZ2Ba1Tu5IFYFZxH7Wj4rg4sQ47zlKBi6gQELgtGV+bCYPAEt/
WQo7uGUCj+xLmBKXuQQlXrl1pNl9XhlufTNXIzW34o7SPKMEQy7N7uUxpxgwV8JX
KoJoYAbiH88=
=9lYm
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Long term development external named branches and periodic merges from python

2011-11-27 Thread Nick Coghlan
On Mon, Nov 28, 2011 at 2:21 PM, Jesus Cea  wrote:
> Since "create patch" (in the tracker) doesn't compare against the tip
> of mainline (at least not in a trivial way), I guess it is comparing
> against the BASE of the branch. That is ok... as far as I don't merge
> changes from mainline to the branch. If so, when diffing the branch
> tip from the branch base it will show all changes in the branch, both
> my code and the code imported via merges.
>
> So, in this context, if the tracker "create patch" diff from BASE, it
> is not "safe" to merge changes from mainline to the branch, because if
> so "create patch" would include code not related to my work.

No, "Create Patch" is smarter than that. What it does (or tries to do)
is walk back through your branch history, trying to find the last
point where you merged in a changeset that it recognises as coming
from the main CPython repo. It then uses that revision of the CPython
repo as the basis for the diff.

So if you're just working on a feature branch, periodically pulling
from hg.python.org/cpython and merging from default, then it should
all work fine.

Branches-of-branches (i.e. where you've merged from CPython via
another named branch in your local repo) seems to confuse it though -
I plan to change my workflow for those cases to merge each branch from
the same version of default before merging from the other branch.

> Anybody knows the mercurial command used to implement "create patch"?.

It's not a single command - it's a short script MvL wrote that uses
the Mercurial API to traverse the branch history and find an
appropriate revision to diff against.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com