[Monotone-devel] Re: push without write access (was Re: monotone comparison, etc.)

[Nathaniel Smith]

On Thu, Jan 27, 2005 at 04:44:53PM +0000, Bruce Stephens wrote:
> Richard Levitte - VMS Whacker <address@hidden> writes:
> 
> > In message <address@hidden> on Thu, 27 Jan 2005 16:07:19 +0100, Christof 
> > Petig <address@hidden> said:
> 
> [...]
> 
> > christof> I don't care for the exact syntax. "push_via_stdout" might
> > christof> be describe it better.
> >
> > I just realised I misunderstood you.  You didn't really mean that to
> > work off-line, did you?
> 
> I think the idea is just for an alternative way of sending things.  I
> can see that being handy sometimes if you've only got read access to a
> remote repository for some reason, and you've got some other means of
> sending.

yeah; and this is a really important use case.  it describes 90% of
the people on this list, for instance, and every new developer you'll
ever have...

there's no technical reason we can't do it, either.  the only tricky
part is that the way netsync works is:
  - use iterated refinement on merkle tries to synchronize keys and
    certs
  - if I'm a sink:
    - I then request all revs mentioned in those certs
      that I don't have
    - I then scan over those revs, reconstructing manifests (or maybe
      requesting deltas, I'm not sure?), and figuring out what file
      deltas to request
so it seems like the easiest way to support this would be to add a
"non-writeable sink" mode or something -- where anonymous users can
tell the server to act like they were a sink, request certs and
revisions, analyse them, request the corresponding file data etc., but
the server will not actually write anything it receives to its
database.  now add a "non-writing source" mode or something, that acts
just like a source, except (a) whenever it sends a revision or cert or
anything at all, it also dumps out a duplicate packet, and (b) it
declines to send file data (and manifest data, if it turns out
manifest data is transferred at all) at all, but just writes out the
requested deltas as packets.

this feature would be even cooler if we had a human-readable way to
dump packets (like with unidiffs where possible, and readable
changelog messages, and unobtrusive chunks of base64 to carry key data
and signatures and such), so people could read these patches on the
mailing list without importing them, but the basic support described
above would be useful even without this.

-- Nathaniel

-- 
When the flush of a new-born sun fell first on Eden's green and gold,
Our father Adam sat under the Tree and scratched with a stick in the mould;
And the first rude sketch that the world had seen was joy to his mighty heart,
Till the Devil whispered behind the leaves, "It's pretty, but is it Art?"
  -- The Conundrum of the Workshops, Rudyard Kipling