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

[Éric Araujo]

Hi,

> I have a question and I would rather have an answer instead of
> actually trying and getting myself in a messy situation.
Clones are cheap, trying is cheap! <cheap wink>

> Let say we have the following scenario:
> 
> 1. A programer clones hg.python.org.
> 2. Programer creates a named branch and start to develop a new feature.
> 3. She adds her repository&named branch to the bugtracker.
> 4. From time to time, she posts updates in the tracker using the
> "Create Patch" button.
> 
> So far so good. Now, the question:
> 
> 5. Development of the new feature is taking a long time, and python
> canonical version keeps moving forward. The clone+branch and the
> original python version are diverging. Eventually there are changes in
> python that the programmer would like in her version, so she does a
> "pull" and then a merge for the original python branch to her named
> branch.
I do this all the time.  I work on a fix-nnnn branch, and once a week
for example I pull and merge the base branch.  Sometimes there are no
conflicts except Misc/NEWS, sometimes I have to adapt my code because of
other people’s changes before I can commit the merge.

> 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.)

> What if the programmer cherrypick changesets from the original python
> branch?.
Then her branch will revert some changes done in the original branch.
Therefore, cherry-picking is not a good idea.

Regards