[Monotone-devel] Re: Summit brainstorming

[Graydon Hoare]

Markus Schiltknecht wrote:

> Complete? Is there a beginning?

Not that I'm aware of, but I hardly manage to keep up with the NEWS file 
these days, much less all the material on side branches.

> Why a special port? Can't this be part of netsync?

I meant that we could add support to a special port as a trigger for 
*non-monotone* clients (such as CVS) connecting to a server-side translator.

> Am I right with my understanding, that this would allow a working copy 
> 'linked' to a remote database?

Yup. A monotone working copy *or* a CVS working copy. Recall that this 
discussion started out with the insane notion of speaking pserver from a 
monotone server to a CVS client.

> When thinking about 'partial pull', I'm envisioning something more like:
>
> mtn pull --last=100

Yes, I think that's more what most of us have in mind for partial pull. 
I wasn't discussing partial pull though; Christof mentioned partial pull 
as the thing he'd *rather* implement, instead of the pserver notion we 
were discussing.

That's a sensible objection: interacting with CVS is not fun. I imagine 
partial pull would be much easier to implement. It sounds like you'd 
prefer it. Maybe I would also. Maybe there's no point considering 
pserver. It was just an idea I thought I'd elaborate on the possible 
implementation structure of (especially since I think I saw Richard 
check in git-cvsserver.pl)

> I can see that a working copy linked to a remote database would have 
> some advantages, but OTOH I think it's somewhat against monotone's 
> distributed nature. A complete 'partial pull' implementation (as I 
> understand it) would give us most of the above functionality with:
>
> mtn pull --last=1

Yes, it would. It would also be a different thing to implement. It's not 
clear to me which is the more important type of client, or the most 
"intuitive" for users. When in doubt, implement both techniques on 
branches and try them!

> Oh, so you mean, we could do either 3, 4 or 5, right?

Yes, or all 3. Or all 4: also implement partial pull. Or none of the 
above. I'm just tossing out some mental models of "ways of addressing 
the general problem": not all clients want the full history. So one 
option is to permit linking working copies directly to remote servers, 
and another is to permit databases that contain missing pieces.

-graydon