[RFC] Pushkey Concept

Adrian Buehlmann adrian at cadifra.com
Tue Sep 22 17:13:10 CDT 2009


On 22.09.2009 23:56, Matt Mackall wrote:
> On Tue, 2009-09-22 at 13:11 +0200, Adrian Buehlmann wrote:
>> On 21.09.2009 19:29, Greg Ward wrote:
>>> On Mon, Sep 21, 2009 at 7:59 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>>>>>  - puskey(string namespace, string key, string value, boolean force=False)
>>>>>  - listkeys(string namespace)
>>>> I hope you meant 'pushkey' instead of 'puskey' there? I'd prefer
>>>> pushkey to accept a dictionary like {'bookmarks': {'mybookmark':
>>>> '34abc3254'}}, so we can reduce the number of roundtrips if we want to
>>>> push many keys in one go.
>>> OTOH, it's nice to be able to push arbitrarily large mappings without
>>> using arbitrary amounts of memory.  That argues for pushing dicts in
>>> chunks of N keys at a time.  Make N large enough that we don't suffer
>>> too many round-trips, but small enough that we don't use up huge
>>> amounts of memory.  My gut says 1000...5000.  If that's too complex,
>>> though, all-in-one is much better than pushing one key at a time.
>>>
>>> Incidentally, I have a great use case for this protocol extension that
>>> has nothing to do with bookmarks or tags: bugmap.  That is, I have
>>> written an extension for work that associates bug IDs with changeset
>>> IDs.  You use it like
>>>
>>>   hg commit --bug 432 --bug 325 -m"fix two bugs"
>>>
>>> which adds a line to .hg/bugmap.  Around the time of pushing that
>>> changeset, you also need to run
>>>
>>>   hg pushbugs
>>>
>>> which connects to a configured MySQL server and turns the line in
>>> .hg/bugmap into two rows of a bugmap table.  (It then writes a new
>>> empty .hg/bugmap.)  My extension wraps 'push' to make this automatic,
>>> but the manual command is there just in case.
>>>
>>> It would be great if this information could be sent over the same
>>> channel as a regular 'hg push', and let server-side code worry about
>>> turning it into database rows.
>>>
>> What about doing a separate "meta" buddy-repository that
>> describes things in the main repository or its history?
> 
> No thanks. It's either in history or it's not. If you put it in a
> orthogonal history, then you need a whole new set of commands for
> examining that history. I'm not at all interested in that. And if your
> aim is for it to actually be a parallel history, where causality applies
> across the two, well, you're just asking for a headache.

The only command that would be need to examine *that* history
would be to cd into the meta repo dir.

And you've already added some support for subrepos.

> Further, the whole point of bookmarks is to not have history. So
> inventing history-based methods to transmit them is silly.

Hard words.

I've responded to Greg's bugmap example, as that seemed to
potentially extend requirements beyond what's needed by bookmarks
alone.

> I'm in favor of a simple key/value extension like what's being proposed.

Ok. I've heard you.



More information about the Mercurial-devel mailing list