Workflow question: importing upstream builds

[Peter Arrenbrecht]

On Thu, Dec 11, 2008 at 7:09 AM, Giorgos Keramidas
<keramida at ceid.upatras.gr> wrote:
> On Wed, 10 Dec 2008 16:13:50 -0800, "David Frey" <dpfrey at shaw.ca> wrote:
>> Let's say I import a build of some software project as a Mercurial
>> repository.
>>
>> [imported build n]
>>
>> I then make two independent changes.  One takes a couple of steps, the
>> other is
>> simple and only takes one commit.  My repo now looks like this:
>>
>>                    [my change 1p1]---[my change 1p2]
>>                   /
>> [imported build n]
>>                   \
>>                    [my change 2]
>>
>>
>> I then import a new build from upstream.  Lets say that upstream accepted
>> the
>> changes I made in "my change 1p1" and "my change 1p2", but not "my
>> change 2".
>>
>>                    [my change 1p1]---[my change 1p2]
>>                   /
>> [imported build n]----[imported build n+1]
>>                   \
>>                    [my change 2]
>>
>>
>> I was thinking that I could use rebase to move "my change 2" to build
>> "n+1" so
>> the repo would look like this:
>>
>>                    [my change 1p1]---[my change 1p2]
>>                   /
>> [imported build n]----[imported build n+1]
>>                                           \
>>                                            [my change 2]
>>
>> The problem I have is that it's unclear what needed to be rebased and
>> what was
>> accepted upstream.  Does it make sense to do some sort of dummy merge
>> where I
>> do:
>> hg update -C -r {imported build n+1}
>> hg merge -r {my change 1p2}
>> hg revert --all -r {imported build n+1}
>> hg commit -m "dummy merge to eliminate head of changes accepted
>> upstream"
>>
>> If I had done this before and then performed the rebase, I would end up
>> with a
>> repo looking like this:
>>
>>                    [my change 1p1]---[my change 1p2]
>>                   /                                 \
>> [imported build n]----[imported build n+1]-----------[dummy merge]
>>                                                                   \
>>                                                                    [my change 2]
>>
>> Is what I have described a normal practice or am I abusing Mercurial?
>
> This looks ok.
>
> Having [my change 2] as a separate patch rebased on top of the tree
> means that it is easy to "qimport" it, hack a bit more, then when it
> passes review & acceptance tests from the upstream team you can just
> "export" the patch and email it upstream.
>
> Another way of doing the same is, of course, to use two separate clones
> (one for each "feature patch"), and a clean "import clone" for the
> upstream snapshots.
>
> Then in clone #1 you have change 1p1 and change 1p2.  When the upstream
> team sends comments on the changes, you commit more local stuff.  When
> they release a new upstream snapshot you import a new snapshot and merge
> in *that* feature branch.  So you end up with three clones looking like
> this:
>
> === clean import clone ===
>
>    [import 0] --> [import 1] --> ... -> [import n] --> [import n+1]
>
> === start of the feature #1 clone ===
>
>    [import 0] --> [import 1] --> [my change 1p1]
>
> === pull and merge of imports [2..n] into feature #1 clone ===
>
>    [import 0] --> [import 1] --> [my change 1p1] --------> [ merge n]
>                      \                                       /
>                       `---> [import 2] --> ... [import n] --'
>
> === more hacking for feature #1 ===
>
>    [import 0] --> [import 1] --> [my change 1p1] --------> [ merge n] ---> [my change 1p2]
>                      \                                       /
>                       `---> [import 2] --> ... [import n] --'
>
> === pull of import n+1 into the feature #1 clone ===
>
>    [import 0] --> [import 1] --> [my change 1p1] --------> [ merge n] ---> [my change 1p2]
>                      \                                       /
>                       `---> [import 2] --> ... [import n] --+---> [import n+1]
>
> === merge of the n+1 import with feature #1 ===
>
>    [import 0] --> [import 1] --> [my change 1p1] --------> [merge n] ---> [my change 1p2] ---> [merge n+1]
>                      \                                       /                                   /
>                       `---> [import 2] --> ... [import n] --+---> [import n+1] -----------------'
>
> At this point you have a "feature branch" for feature #1, saved
> separately in a clone of its own.
>
> In a second clone, you may be developing feature #2 with a history that
> looks like this:
>
>    [import 0] --> [my change 2p1] --> [merge 2] ---> [my change 2p2] ---> [merge n+1]
>           \                             /                                       /
>            `- .. --> [import 2] -------+---> ... [import n] --> [import n+1] --'
>
> You can still pull *both* features in a single clone, if you really want
> to keep both histories around, and it would generate a history like
> this (re-arranged a bit to keep the 'common' parts in the middle):
>
>                        ,--> [my change 1p1 -----------> [merge 1.n] ---> [my change 1p2]  --> [merge 1.n+1]
>                       /                                   /                                    /
>    [import 0] --> [import 1] --> [import 2] --> ... --> [import n] --> [import n+1] ----------'
>          \                           \                                     \
>           `--> [my change 2p1] --> [merge 2.2] -------------------------> [merge 2.n+1]
>
> But you don't really *have* to pull all features in the same clone.  They
> can live in their own separate, per-feature clone as long as necessary :)
>
> It seems from your original post that you are trying to develop two
> features in the same Hg clone.  If you keep a separate "import clone"
> with the snapshots of the upstream source and a separate feature clone
> for each separate feature, then you can pick & choose which snapshots to
> pull into each feature clone.
>
> It may be convenient, for example, to refrain from merging with [import
> n+1] before some of the work in feature #2 is finished (i.e. because n+1
> changes the API in annoying ways, and you are still working out the
> details of feature #2].  At the same time, it may be useful to pull
> *all* imports into the feature #1 clone, because the specific feature is
> essentially finished, and there are no changes in import n+1 that affect
> this particular feature.

You might also want to look at the pbranch extension, which builds
some infrastructure around the concept of developing individual
patches in separate branches within a single repo:

  http://arrenbrecht.ch/mercurial/pbranch/

-parren