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