[Python-Dev] Long term development external named branches and periodic merges from python
jcea at jcea.es
Mon Nov 28 05:21:18 CET 2011
-----BEGIN PGP SIGNED MESSAGE-----
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:
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.
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
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 _/_/ _/_/_/ _/_/_/
jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/
. _/_/ _/_/ _/_/ _/_/ _/_/
"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/
-----END PGP SIGNATURE-----
More information about the Python-Dev