First, incomplete, but promising stab at converting pbranch scenarios to "changeset evolution"

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Thu Sep 1 06:50:08 CDT 2011


On Thu, Sep 1, 2011 at 1:05 PM, Idan Kamara <idankk86 at gmail.com> wrote:
> On Thu, Sep 1, 2011 at 1:16 PM, Peter Arrenbrecht
> <peter.arrenbrecht at gmail.com> wrote:
>>
>> On Thu, Sep 1, 2011 at 11:43 AM, Pierre-Yves David
>> <pierre-yves.david at logilab.fr> wrote:
>> > On Thu, Sep 01, 2011 at 11:26:00AM +0200, Peter Arrenbrecht wrote:
>> >
>> >> >> Because of:
>> >> >>
>> >> >> >> parren: So merging 4 and 6 is going to conflict on a, which
>> >> >> >> merging 3
>> >> >> >> and 5 will not, is that it?
>> >> >
>> >> > Not if you use (1) are common ancestor of 4 and 6. After discussion
>> >> > with Idank
>> >> > the simplest way seems to make mercurial consider "evolution"
>> >> > relation as "real
>> >> > ancestors" relation during such "evol-merge". This way we'll get a
>> >> > simple
>> >> > standard merge of difference between 4 and 6 from 1.
>> >>
>> >> This sounds like a can of worms. How do you, for instance, implement
>> >> rename tracking properly? I fear we would end up duplicating a lot of
>> >> logic that we'd all get for free (and could continue to maintain in a
>> >> single place) if we found a way to leverage Hg's existing DAG for
>> >> patch evolution.
>> >> -parren
>> >
>> >
>> > You just provide me the first convincing reason[1] to keep the "delta"
>> > changeset
>> > that you create above amended one before creating a new one. Having this
>> > changeset explicit changeset can make all "evol-relation" empty of any
>> > difference with its parent.
>>
>> I think we do need a place where to stick the `amdend --note "..."`
>> comments. The commit message of the update changesets are a natural
>> fit.
>>
>> > I need to think a bit more about it (in particular the fact that we may
>> > not
>> > have all step that lead from a changeset to another).
>> >
>> > I still believe that excluding "evol-relation" from the changeset hash
>> > is an
>> > hard requirement for evolution.
>>
>> Absolutely. My current line of thought is that the pbranches stay
>> hidden, and whenever you amend a cset, it performs the update on its
>> dedicated pbranch branch, and then creates a new current version of
>> the patch as a regular changeset, properly based on the parent of the
>> amended changeset.
>
> I had the same thought after reading pbranch docs. It really
> simplifies things
> when collaboration comes into play. Almost all scenarios come down to simply
> merging branches, using existing facilities out of the box. Other operations
> are trickier but some of them already handled by pbranch.
> Managing the "pseudo" changesets might prove to be a bit cumbersome though,
> since they should be local.

How "local"? You mean they should not even propagate between
collaborators? I think they easily could.
-parren


More information about the Mercurial-devel mailing list