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

[Stephen Leake]

John Bailey <address@hidden> writes:

> A user has no write access to any public netsync servers and is behind
> a firewall he does not control (thus can't run a netsync server). This
> user has taken an interest in some section of the project and begins
> committing minor bugfixes and feature additions to his local database.
> Now he'd like to send the revisions he committed in some manner.

I think this is a reasonable scenario.

There are two separate issues: 

1) transporting the change info thru (or around) the firewall

2) committing the change info to a central server (requires write
   access)

The only solution to 2) is to have someone with write access do the
sync.

Using a patch file (via email or some other transport) is one solution
for 1; I hope it's the last choice.

Other choices are:

1) netsync via ssh: . That is relatively easy to get thru firewalls
   (many already allow ssh, but of course that depends on the firewall
   configuration).

   Note that the normal mtn write permission mechanisms are suppressed
   when using ssh:; if you have ssh login to the machine hosting the db,
   mtn gives you write permission to the db (subject to OS permissions).
   So this can be a solution for 2) as well.

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.

Hmm. Email servers often have file size limits. So if the file transport
mechanism is email, then a patch file will work where a mtn database (on
a relatively large project) will not.

I think it's unlikely any lab rules will permit email but no other file
transport. But I have not surveyed every lab, obviously :).

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.

-- 
-- Stephe