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

[Stephen Leake]

John Bailey <address@hidden> writes:

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

I left out a step:

Some developer (let's say Beth) with write privs to a public netsync
server aggrees to give write access (either directly or via some patch
mechanism) in her local database to the new user (Alan).

So Alan has effective write privs on Beth's database. That would be via
ssh, in this scenario.

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

This should be "sync with Beth" rather than "netsync via mtn:". Sorry, I
was focussing on the firewall issue.

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

Using standard mtn commands; log, diff, Emacs DVC, monotone-viz, etc.

> With a patch, or a series of patches, it's simple, as you have the raw
> diff to look at. 

Generate it with mtn diff. Personally, I prefer Emacs DVC to mtn diff.

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

No, it's a complete mtn database on its own; mtn diff will work just
fine.

You only need to sync it with some other db once you are happy with it.

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

Yes, the first revision

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

Ah; good point.

To persue this solution a little further, Alan could execute

mtn export --no-base --from REV alan.patch.db 

which would leave out the base REV, and include only the deltas. Then
Beth could execute

mtn --db alan.base.db export --as-base REV

to generate a db with just the base rev, and then

mtn --db alan.base.db pull file://alan.patch.db

<review, approve>

mtn --db beth.db pull file://alan.base.db


Compare that to the patch process:

Alan:

mtn patch --from REV alan.patch

Beth:

mtn checkout --branch foo --revision REV

patch < alan.patch

<review, approve>

mtn commit


One extra step in the db based process. That could be easily handled in
a bash script, or other front end.

-- 
-- Stephe