John Bailey <[email protected]> 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
