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

Idan Kamara idankk86 at gmail.com
Thu Sep 1 06:05:40 CDT 2011


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110901/27768338/attachment.html>


More information about the Mercurial-devel mailing list