Re: [Monotone-devel] Commit without working copy

[Grzegorz Jakacki]

Nathaniel Smith wrote:
> > > (With the .restrictions branch, this becomes some virtual working copy
> > > with some changes masked out, but this doesn't change things
> > > conceptually --- conceptually, we always commit a complete snapshot.)
> >
> > OK. Assume my repo has just one file.
> >
> >
> > > So what you're asking for seems to be of very limited utility,
> >
> > Not to me.
>
>
> Well, obviously it's useful to you :-).  What I meant was, you have to
> assume that your repo has only one file, etc., for it to be useful,
> which makes it unlikely to be useful to most other people.

First, what I am trying to do makes sense with more files too. I asked 
you to make this assumption since it is easier to understand that way.

Second, I am not asking to add any feature, so usefulness to general 
public is not a concern here.

> > > and
> > > semantically weird --- neither really good bets for getting it folded
> > > in upstream, at least at first blush :-)
> >
> > I am not requesting a new feature. I am asking how difficult it
> > is to add it and where should I look first if I wanted to add it myself.
>
>
> Okay.  But, I'm also guessing, part of being "useful to you" is
> probably that it works with standard Monotone, 

Right.

> i.e. you don't have to
> maintain your own fork of Monotone itself just to accomplish your
> goals.

If my desired functionality can be added just by appending code to 
commands.cc, then I don't need anything more.

> > > What are you really trying to do?
> >
> > I am trying to prototype distributed Wiki system.  A peer of such system
> > is a repo and webserver. PHP interpreter working on the webserver
> > checkouts webpage from the repo and serves it to the webclient. If user
> > edits the page, php script commits the page back to the repo and merges.
> > From time to time state of repos is propagated among peers and merged
> > wherever possible.
>
>
> Huh, neat idea.  How are you planning to handle merge conflicts?  

System performs word-oriented automated merge wherever possible, leaving 
all problematic merges up to the users.

> I'm
> curious too what benefits you expect from having multiple peers?

Ability to edit wiki off-line.

In general, these are my requirements:

- users cannot rely on fast connection to wiki server,
- users need to be able to modify wiki off-line on their
  private machines,
- users need to be able to modify wiki from public
  networked machines (e.g. in internet cafe),
- apart from web iface, users need to be able to edit wiki
  pages with plain text editor,
- the webserver serving wiki should avoid storing
  data as files.

> > AFAIU from reading docs it is doable with monotone. I just wanted to
> > know if there is a way to commit/checkout directly to/from the webclient
> > (via webserver running, say, PHP).
>
>
> It should indeed be doable with Monotone.  What I'd recommend would be
> just to do a checkout.  The PHP equivalent of the shell:
>   DIR=`mktemp -d $TMPDIR/mywiki-checkout.XXXXXX`
>   trap "rm -rf $DIR" EXIT
>   monotone checkout --branch=$BRANCH $DIR
>   cat newfile > $DIR/file
>   (cd $DIR; monotone commit $MSG)
>
> A little annoying to create the temp dir, yeah, but it's not really
> that hard to do safely...

I would like to avoid this route if possible.

> Also, note that you need some locking to make sure that only one
> 'monotone' subprocesses runs at the same time to access the same
> database; Monotone won't corrupt your data in any case, but will error
> out rather than blocking and waiting for the DB to become available.

Is this monotone's or SQLLite's problem? I don't know SQLLite, but it 
looks like it does not support multiuser access, does it? What if I 
replace SQLLite with multiuser ACID-compliant database and have many 
monotones modifying this database concurrently?

Best regards
Grzegorz