[Python-Dev] Long term development external named branches and periodic merges from python (original) (raw)

Jesus Cea jcea at jcea.es
Mon Nov 28 05:21:18 CET 2011

-----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 // /// /// 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/

iQCVAwUBTtMMPplgi5GaxT1NAQKzhQP8DzAql1PAJkyEROsWl8CgPpW9ie8jNM1V +K5jLx/dCukzFXrZ2Ba1Tu5IFYFZxH7Wj4rg4sQ47zlKBi6gQELgtGV+bCYPAEt/ WQo7uGUCj+xLmBKXuQQlXrl1pNl9XhlufTNXIzW34o7SPKMEQy7N7uUxpxgwV8JX KoJoYAbiH88= =9lYm -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list