Re: [Monotone-devel] Question on layering

[Daniel Carosone]

On Thu, Feb 22, 2007 at 09:12:36AM +1100, William Uther wrote:
> What happens at the moment when you're running mtn serve on a db  
> _and_ using it to check out, etc?  What happens at the moment if you  
> mtn serve something twice? (I just started two servers on the same db  
> and they both started - didn't try to sync to them.) 

One or other of them will bomb out failing to take the exclusive write
lock in the sqlite code, when they sooner or later collide.

> Is this a case of "don't do that"?

Pretty much.  A different db for serving is recommended practice;
there's some discussion of this in the later sections of the totorial.

> My next thought is to write something like sshns:// (ssh+netsync)  
> where it uses ssh to tunnel to the remote machine, and then connects  
> to a netsync server already running.  

I do this with -L port forwarding to a running server frequently.

> At the moment netsync is working reliably, so I'm assuming the  
> problem is with the piping to a child process on windows.

> >>Features for interacting with current hosting services:
> >>
> >>  iv) A format for storing a monotone repository in a subversion
> >>server.
> >
> >I think you're mixing up two distinct things here -- mirroring between
> >a mtn history and a svn history, and using an svn server as a generic
> >file store for something like mtn-dumb.
> 
> Yes.  Deliberately.  Imagine you want to use sourceforge as a host  
> for a monotone repository.  You're going to want to have both.   

Er, not really.  You'd be storing all of history twice: the monotone
history, and the svn history of the monotone history in the .dumb
files, including every version of all the merkle trees.  It
seems.. unnecessary at best.

> I guess I was assuming that writing it as a cache might be easier  
> than the horizon stuff.  It doesn't change the logic, it just changes  
> where you get your data from.  If it isn't local, then grab it over  
> the network.  I would expect log and annotate to hit the network and  
> be ugly.

Yeah. Right now, we have a very nice clean model of which operations
are online or offline.

However, it also does change the logic: quite a bit more protocol is
required for the client to specify the request, so the server can
figure out which revisions are needed for that request, because, see,
the client doesn't know.

We've toyed with various models where we have selective histories:
full revision data but not content, as one example. Each has their
complexities.

> >>  vii) convenience commands.  mtn clone == mtn pull --partial && mtn
> >>co (and puts the partial repository in the _MTN directory of the
> >>working copy).  mtn pcmp == mtn pull && mtn commit && mtn merge &&
> >>mtn push.  mtn pu == mtn pull && mtn up

Yeah. One user expressed this to me as "I want a 'mtn
go_home_at_the_end_of_the_day'" command, but with a better name."
This example would do something like commit, pull, merge-if-needed,
sync, merge-again-if-needed, ..., update.

We have nice simple discrete commands at the moment. I personally like
this, but users do tend to struggle trying to remember sequences, so
some "macro" convenience routines like this have been considered.

There's also the simple complication of naming. Some users arrive from
other tools with expectations that command names like "update"
overload several of these functions at once.  Again, I like that we
tease these complexities apart and help people to think of the
differences between them (so you can commit before update and avoid
merging with uncommitted work, etc), but I'm less certain whether the
discrete or "macro" commands should have the common names, like
"update".

It needs careful thought with a strong focus on consistency in the UI.

> How about making --partial the default for pulls and clones, and full  
> transfer the default for syncs.  That captures the both the "I'm just  
> testing bleeding edge" and "I'm actually a developer" use cases.  You  
> clone the first time and get a partial db.  The first time you sync,  
> you get the rest.

I don't think that's a great idea in the simple case: I shouldn't find
myself suddenly pulling down huge history just to send my first new
head.

> Another suggestion:  In the log, when a revision is a merge, if  
> either of the parent revisions is from a different branch, then tell  
> me which branch it is from.

There's two wrinkles here: first, revs can be on multiple (or no)
branches, so there's room for ambiguity here both with respect to when
the condition matches, and what to print when it does.

Secondly, in common usage, the merges you're talking about are
typically created with the "propagate" command, and this by default
records exactly the information you're looking for in the commit log
already :)

> Finally, is there a good place to list these suggestions?  I looked  
> on the wiki for a page with "suggest" in the title, but couldn't find  
> one.

Feel free to start one; there are a number of pages for larger
wished-for features, as well as the QuickieTasks page and a WishList
page to index them might help considerably.

--
Dan.

pgpmkqSM9SiQS.pgp
Description: PGP signature