[PATCH 3 of 7 upgraderepo V2] repair: determine what upgrade will do

Augie Fackler raf at durin42.com
Tue Dec 13 11:17:07 EST 2016


On Mon, Dec 12, 2016 at 12:34:31PM +0100, Pierre-Yves David wrote:
>
>
> On 11/25/2016 04:28 AM, Gregory Szorc wrote:
> ># HG changeset patch
> ># User Gregory Szorc <gregory.szorc at gmail.com>
> ># Date 1480035243 28800
> >#      Thu Nov 24 16:54:03 2016 -0800
> ># Node ID 328d95ac1fd128359a2665f2959e030ee8cce046
> ># Parent  4fffbdc2bca22e666482b55562c0e592c8a68027
> >repair: determine what upgrade will do
> >
> >This commit is rather large. It started off as multiple commits
> >but I couldn't figure out a good way to split up the functionality
> >while still conveying the overall strategy. To the reviewer, I
> >apologize.
>
> From a reviewer: this changeset is just too large

It's much smaller than it looks - it's mostly configurational stuff
that's easy to work through. I've provided Greg with some comments,
and would welcome the change being resent without splitting it into
tons of patches (which might be a lot of work for relatively little
practical benefit.)

> , I've currently too much
> backlog on my plate to dive into such scary monster. I've looked into that
> area myself and I don't see why we could not have something more iterative.
> I could see two ways to go here,
>
> Proposal 1: detect all then implement all
>
>   1. detect possible upgrade A
>   2. detect possible upgrade B
>   3. detect possible upgrade C
>   4. detect possible upgrade D
>   5. implement upgrade A
>   6. implement upgrade B
>   7. implement upgrade C
>   8. implement upgrade D
>
> Proposal 2: detect then implement iteratively
>
>   1. detect possible upgrade A
>   2. implement upgrade A
>   3. detect possible upgrade B
>   4. implement upgrade B
>   5. detect possible upgrade C
>   6. implement upgrade C
>   7. detect possible upgrade D
>   8. implement upgrade D
>
> Can get your to submit a new series with smaller patches? Ping me on IRC if
> you have extra questions. (I would not be surprised if we end with multiple
> sub-series).

I'd rather not split this series too far - it's a good conceptual unit right now.

>
> Cheers,
>
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list