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

[John Bailey]

On 08/11/2010 05:56 AM, Stephen Leake wrote:
> 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.

If a user (untrusted contributor) has no write access to any public netsync
server, why would a project be stupid enough to grant him SSH access to a
machine under their control (even if it's a developer's personal machine)?
Remember that this whole scenario is about new contributors that have no prior
affiliation with a given project wanting to transport his revisions to the
developers of said project.  SSH access, and knowledge of how to use it, cannot
be assumed, thus making this option not viable.

> 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.

If a user has no netsync access to *any* public netsync server, how does this
solve, or even help, his problem?  As I mentioned above, netsync via SSH is not
a viable solution to this scenario.

<snip>
> 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 might work, but how does the receiver then review?  With a patch, or a
series of patches, it's simple, as you have the raw diff to look at.  In this
case it sounds suspiciously like the database sent via e-mail is completely
useless until its revisions are put into another, more complete database.  That
may be fine in the case of a small number of revisions, but if the person has
sent me 100 revisions, there's no way I'm going to deal with the potential of
having to kill_rev_locally every one of them if I find the contributor's work
unacceptable.  Yes, I could keep a backup of the database from before the
changes are imported, but this is making a workflow needlessly more complicated.

From my understanding, if this "partial pull" database is to be useful in any
way without pulling its revs into a more complete database, it must have
*something* to base the diffs on--that is, there must be some complete revision
for the first revision's diff to be relative to.  In the case of any project of
reasonable size, such as Pidgin, this breaks the transport-via-email idea, as
our base source tree is some 60 MB, which would yield an unreasonably large
database that the user would be expected to transport in some fashion.

John

signature.asc
Description: OpenPGP digital signature