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