merging conflicting patches with pbranch
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Wed Oct 21 06:45:33 UTC 2009
On Tue, Oct 20, 2009 at 9:29 PM, David Holland
<dholland+hg at eecs.harvard.edu> wrote:
> On Mon, Sep 21, 2009 at 08:02:54AM +0200, Peter Arrenbrecht wrote:
> > So the first question is: Why do you want to move from pbranch to a
> > patch series when really your patches are and should remain a DAG? Is
> > this just for reviewing them?
>
> Mostly, yes. Well, in the long run I'd like to be able to ship the
> patches as patches (one per branch) so the person downloading the
> system can pick and choose the things they want. It would be most
> convenient to do this via hg pexport rather than by explicitly
> extracting diffs of this and that, but it probably isn't practical.
>
> > If so, then you're proposal for using
> > something like `diff3 -x` for hidden branches and outputting results
> > (if any) in pexport is interesting. However, pbranch currently uses
> > octopus merges at the patch level (not at the changeset level,
> > obviously), hence the single hidden branch used to merge n parent
> > patches. It would have to change to use multiple cascading hidden
> > branches to use only two-parent patch merges. Otherwise, we would need
> > `diffN -X` :)
> >
> > If this is your need, could you please experiment with the
> > diff3-output to see if that would really help? And which options to
> > diff3 would be best?
>
> Now that I have imported the thing and therefore have practical
> experience I don't think it's important enough to worry about.
>
> > > 2. [...]
> >
> > Agreed. Could you please file a bug at
> >
> > http://bitbucket.org/parren/hg-pbranch/issues/?status=new&status=open
> >
> > > And also, [...]
> >
> > Again, could you please file a bug.
>
> Done. Sorry about the delay.
>
> I have two more issues at this point. One is, unfortunately,
> performance:
>
> % wc -l .hg/pgraph
> 50 .hg/pgraph
> % time hg pgraph -s >/dev/null
> 971.000u 0.000s 17:46.76 91.1% 0+0k 0+1io 0pf+0w
> %
>
> This is slow enough to be a problem; it doesn't take fifteen minutes
> each time to change branches or run hg pmerge, but it does take a
> while (at least at the top of the graph) and it's enough to get
> seriously in the way of progress.
>
> Admittedly the machine I'm using is no speed demon, but nonetheless a
> graph of 50 nodes isn't particularly large; there must be something
> silly going on.
Indeed. Shall have to look into it.
http://bitbucket.org/parren/hg-pbranch/issue/36/performance-with-lots-of-patches
> The other issue is that it seems that if you have densely connected
> branches that you often seem to have to do the same merges over and
> over again. That is, given
>
> default
> | \
> red |
> | \ |
> | iron
> green |
> | \ |
> | copper
> blue |
> \ |
> silver
>
> it seems that if I add a change to "red" that causes a conflict in
> "iron" and merge it by hand, I then end up having to do the exact same
> merge again in both the "copper" and "silver" branches. This may
> depend on the order of dependencies in the pgraph file -- I think the
> problem is that it merges from the sequence that generates the
> conflict first, so you have to resolve by hand, and only after that
> does it merge in the resolved version you already did. (But maybe that
> isn't the issue; plus depending on the symmetry of the patch graph,
> rearranging the dependency ordering would probably just rearrange
> which conflicts need to be re-merged.)
>
> I can try to prepare a specific simple example if you want.
I actually have the same case right now.
http://bitbucket.org/parren/hg-pbranch/issue/37/need-to-resolve-same-conflict-repeatedly
-parren
More information about the Mercurial
mailing list