[PATCH 5 of 7] changegroup: deprecate 'getlocalchangroup' (API)

Augie Fackler raf at durin42.com
Fri May 5 18:44:56 EDT 2017


On Fri, May 05, 2017 at 12:16:50PM -0700, Martin von Zweigbergk via Mercurial-devel wrote:
> On Fri, May 5, 2017 at 11:44 AM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
> >
> >
> > On 05/05/2017 08:38 PM, Martin von Zweigbergk wrote:
> >>
> >> On Fri, May 5, 2017 at 11:35 AM, Pierre-Yves David
> >> <pierre-yves.david at ens-lyon.org> wrote:
> >>>
> >>>
> >>>
> >>> On 05/05/2017 06:41 PM, Martin von Zweigbergk wrote:
> >>>>
> >>>>
> >>>> On Thu, May 4, 2017 at 11:26 PM, Pierre-Yves David
> >>>> <pierre-yves.david at ens-lyon.org> wrote:
> >>>>>
> >>>>>
> >>>>> # HG changeset patch
> >>>>> # User Pierre-Yves David <pierre-yves.david at octobus.net>
> >>>>> # Date 1493894621 -7200
> >>>>> #      Thu May 04 12:43:41 2017 +0200
> >>>>> # Node ID 2f51cfeac5bcf8ee266a6fada56517d5d44d9b6b
> >>>>> # Parent  1e8427b7d0b9ce66c5ba34c2cdb64821ff909267
> >>>>> # EXP-Topic changegroup.cleanup
> >>>>> # Available At
> >>>>> https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
> >>>>> #              hg pull
> >>>>> https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r
> >>>>> 2f51cfeac5bc
> >>>>> changegroup: deprecate 'getlocalchangroup' (API)
> >>>>>
> >>>>> We have 'getchangegroup' with a shorter name for the exactly same
> >>>>> feature. Now
> >>>>> that all users are gone we can formally deprecate it.
> >>>>
> >>>>
> >>>>
> >>>> We usually just delete methods that we no longer use internally. Why
> >>>> not do that here?
> >>>
> >>>
> >>>
> >>> When function are likely to be used by extension we try to avoid dropping
> >>> them and we deprecated them for a version. This helps third party
> >>> extensions
> >>> to smoothly detect the API changes (usually through test run) and
> >>> smoothly
> >>> upgrade their code over the version cycle.
> >>
> >>
> >> In this case I suspect it won't help many of them because I probably
> >> broke most or all anyway with
> >> https://www.mercurial-scm.org/repo/hg/rev/282b288aa20c. I thought we
> >> were okay with that kind of changes. Are you saying I should have
> >> instead added duplicate methods with the new signatures and only
> >> deprecated the existing methods?
> >
> >
> > Generating changegroup is a quite core feature in Mercurial. I suspect their
> > are extension out there using these and I tried to be careful. That is a gut
> > feeling. I'm did not looked at actual data. (that gut feeling proved right
> > for "vfs", but might be wrong here)
> >
> > (so, yes I would have been more careful with your API change too)
>
> Well, given that my patch probably broke most of those extensions, I
> don't see much reason for your series to be more careful. But there's
> little harm in doing it, so I'll queue it once tests have run etc.

FWIW, my gut feeling is that few-to-no extensions are likely to
generate bundles. I've done lots of awful invasive stuff in extensions
and never actually generated bundles as part of them.

(I don't feel strongly about preserving compat either, but my feeling
on API stability is that our warnings should be seen by extension
authors as best-effort and not reliable.)

>
> >
> > 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