Re: [Monotone-devel] Re: removal of packet functions

[Ethan Blanton]

Stephen Leake spake unto us the following wisdom:
> 2) netsync via file: to a mtn db on a USB drive, physically transport
>    the USB drive around the firewall, netsync via mtn: from there.
> 
> Some really secure labs forbid both 1 and 2 for security reasons (holes
> in firewalls are dangerous, USB drives can harbor viruses), so having a
> third choice of "dump patch to file, transport file outside the
> firewall, import patches" seems reasonable.
> 
> However, that "transport file outside the firewall" step is the hard
> part. Any file transport mechanism that can transport a patch file can
> also be used to transport a mtn database, enabling a variant of solution
> 2). I think that should be the recommended mtn approach.

This is bogus in the current state of the world.  Monotone databases
are *huge*.  Transporting a 500MB Pidgin database to communicate 4kB
of patches is unreasonable. Transporting an xxdiff/etc. of a database
is not safe or portable.

I am somewhat distressed at this continuing loss of non-netsync-based
communication functionality in monotone.  At the time that exporting
revisions disappeared (years ago), it was my understanding that a dumb
transport and/or readable patches were going to appear to replace it.
Nothing has happened on this front, and there's still no way to
schlepp around monotone revisions with metadata.

The argument that "monotone revisoins are harder than patches" is also
bogus.  Yes, you can't apply a revision for which you don't have a
parent -- so what?  There are plenty of cases where there's some sort
of basis which you can assume that the other party has access to.  For
example, I mightw ant to send John all of the revisions in my database
which are on the im.pidgin.pidgin branch, but which don't appear on
mtn.pidgin.im.  I really should be able to dump those out in some way
such that he can import them with metadata intact, and when we
mutually sync to pidgin.im, we don't see duplicate revisions requiring
merge.  I view monotone's inability to handle this as a shortcoming
which is awaiting solution.

> Which raises the old question of "partial pulls"; maintaining a database
> that has a limit on old history. In this case, the history would be
> limited to the start revision, yeilding a very small database, that
> should get thru an email server.
>
> Then we need a command 'mnt export_db --from REV' to create the small db
> containing recent history.

This sounds like a reasonable solution to the problem.  I think an
ASCII format would  be superior, but not enough so that I'd fight
about it.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature