D1551: remotenames: consider existing data while storing newer data

Sean Farley sean at farley.io
Wed Dec 6 13:36:00 EST 2017


durin42 (Augie Fackler) <phabricator at mercurial-scm.org> writes:

> durin42 added a comment.
>
>
>   I'm landing this series as-is, even though there are some good ideas for how we could improve the storage layer. My reasoning is this: we've had this as a semi-popular extension for literally years, it's functionality that we know is useful, and it'd be better to land something good rather than never land it in the name of wishing for something better. We've got almost two full months left in the cycle before this even ships as an experimental feature, so if anyone wants to try and iterate aggressively on the format I'd be delighted to talk over goals and review patches (but I'm far too busy to do any coding work, alas.)

I hadn't finished writing my review of this patch, so that's awesome. I
have many concerns for this as-is. We need to have some kind of
measuring stick for quality in core instead of saying, "perfect is the
enemy of good," and letting everything through.

I'm not asking for perfect. I'm asking for this to be reworked to
something consistent for core. We haven't had a file format so external
pushed to core so quickly before. Histedit, journal, schemes, and even
mq have their own file formats which have been ironed out in hgext/.

For this patch as-is, it should at the very least be named
logexchange.py or something similar. "remotenames" is weird name to have
in core and already conflicts with the name of the extension it comes
from. I plan to back this out because there are so many things that need
to be worked out before this lands.

What happened to our quality for core?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171206/4a863fae/attachment.sig>


More information about the Mercurial-devel mailing list