sydney mini-sprint, kickstarting 0.16, roadmap for 0.16

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> Robert Collins wrote:
>>> hpss first-pull optimisation
>>> hpss first-push optimisation
>> In terms of hpss optimisation, it might be worth looking at Monotone's
>> netsync protocol.  Apparently, they're able to use Merkle Tries to
>> determine the missing revisions without sending a lot of revisions.  I
>> can't say much more, as I don't know that math very well.

> I think it makes the most sense for them, because they are already
> working on sha hashes for revision handles.

Do you mean because each revision includes the hashes of its parents?

> Mercurial uses "branch-points" based on what "heads" are currently
> present in a repository:
> http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol

When we had the Mercurial meetup, they were looking to replace that-- to
find something that would scale well to a million revisions.  We looked
at bloom filters
http://mebentley.blogspot.com/2006/06/bloom-filters-and-smart-servers.html
but Nathaniel Smith later suggested the Merkle Tries they use.

> 2) We really want to leverage the ancestry aspect, I also think we can
> have a dialog between client and server. Where the client could say "I'm
> interested in what you have, and here is a sampling of what I have". And
> the server can use that to give ideas of what to request.

A bloom filter could be used there.  If you are only doing a "sampling",
you may be able to get acceptable error rates with less than 500K.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGCTAj0F+nu1YWqI0RAmG5AJ9Mx6GMV1LBHYf7jUDxwQNkk+LjgQCeNqnr
HbXxnHga3FJv7cKAy4RGqyA=
=W7Gg
-----END PGP SIGNATURE-----