[RFC] Pushkey Concept

[Adrian Buehlmann]

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?

Things of the sort of bugmap would be added to the meta repo.

If the meta info is in a repo as well, changes to the meta
info can be tracked, so you can see how it evolved.
And we get cloning, pushing and pulling for (almost) free,
using the existing infrastructure.

The meta repo would have a fixed relative url.

Commands using meta information would use the tip
revision of the meta repo by default (even if the main repo's
working parent is not the tip of the main repo).

For example, if you 'hg up' the main repo, the meta repo
stays at tip (tip of the meta repo, that is).

The idea is that the meta repo describes the
main repo with its full history.

The meta repo at revision r assumes the existence of
a set of revisions H in the main repo: the heads that
were present in the main repo when r was created.
H might be stored explicitly in x (as a set of hashes),
or just assumed implicitly.

The meta repo should be cloned together with its
main repo.