[RFC] Pushkey Concept

[Matt Mackall]

On Wed, 2009-09-23 at 00:13 +0200, Adrian Buehlmann wrote:
> 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.

It's still a second system. Currently everything that is in history is
in the repository. Tags, signatures, etc. Adding a parallel history for
something that -by design- doesn't track history is extremely
incongruous.

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

I consider 'silly' to be quite tame. And it's certainly toned down from
my initial hair-pulling response to seeing this sort of scheme suggested
for the nth time.

-- 
http://selenic.com : development and support for Mercurial and Linux