What's next for pbranch?

[Peter Arrenbrecht]

On Wed, Nov 25, 2009 at 1:10 PM, Waldemar <waldemar at beechwoods.com> wrote:
> On 11/25/2009 01:09 AM, Adrian Buehlmann wrote:
[snip]
>> Well, this really starts me thinking whether pbranch is truly the right
>> thing for such a heavy use case (20 engineers, 6 six different sub-
>> contracting firms...).
>>
>> Offhand, I would say try finding a structure that works with using plain
>> Mercurial (for a project of *that* size).
>>
>> Why don't you setup one separate line of development for the big piece
>> and two other separate lines for the two optional little pieces?
>>
>> A "line of development" could be a separate repository or a named branch.
>>
>> And I guess it would make sense to have them all start off from the same
>> common base revision.
>>
>> Then merge between these lines of development and the main line
>> (main repository or the default branch in case of named branches).
>>
>> Keep it as simple as possible!
>>
>
> Which is why I said "contemplating" in the original post.  In fact, what we
> did was exactly what you describe above but this proved quite involved.
>  There was just too much synchronization going on.  We eventually gave up on
> maintaining three different lines of development in favor of a single stream
> and splitting every deliverable three way every time.  This is a manual and
> error prone procedure which sounds terrible but in the context is less
> expensive because it does not involve the entire team.  What would be nice
> is if we could do the manual splitting once and then somehow make mercurial
> remember what belongs where while the project runs.  That's when pbranch
> caught our attention.
>
> There is another way. We could put them on three different named branches
> but then we would need to have the ability to merge them into working area
> while leaving branch heads open.   Maybe all we need is to extend "hg up" a
> little bit to perform a merge, not a check out.  I don't know how check-in
> would work in this scenario.

Yes, pbranch basically orchestrates recurring flows of merges between
branches. But you could automate this using scripts if your merge
structure doesn't change much. However, the upcoming octopus merge
conflict resolution in pbranch is what you would be missing out on.

Maybe it would be good to be able to use a pared-down pbranch that
only does the orchestration and not the patch management added on top.

(Seems to me I should try to do a better job at explaining what
exactly pbranch is and does.)

-parren