Revfile vs Atomicity & Dumbfs

[Martin Pool]

On  9 May 2005, John A Meinel <john at arbash-meinel.com> wrote:

> Except if you are rewriting 10 different files, then you have to make
> them all go "pop" at the same time. The issue with bzr is that it keeps
> each file separately, and so you don't have one directory/file to change
> to say everything is done.

Yes you do.  revision-history.

> >| and atomicity. And unless I'm mistaken, it is easier to add a new file
> >| to a remote connection, than it is to append to an existing one (at
> >| least with sftp/ftp, webdav may be different).
> >
> >AIUI, sftp handles appends with aplomb.  It's webDAV that's not reliable
> >for that.  And Martin hasn't committed to using webDAV for write:
> >"perhaps for writing it is reasonable to require a svn+ssh style server
> >invoked over a socket"
> >http://bazaar-ng.org/doc/design.html
> 
> However, this still breaks the dumbfs implementation. Now if he is
> saying ssh access for write access, that isn't a big deal. But if you
> have to have a server for write access, you don't have a dumbfs.

Several things here:

You can do efficient append-only updates to revfiles over sftp.
WebDAV may be less efficient but to me it seems to be uncommon.

A smart server can almost always be faster and safer than a dumbfs; we
can support both.


> >| What about the plugin system? I think I could play around with having a
> >| directory for adding external commands, where the files can be
> >| introspected so that they show up in something like "bzr help commands",
> >| or maybe "bzr help extras".
> >
> >That would be cool.  I'd like it to be a directory of directories, so
> >that you can have commands from multiple sources.  

mpe's patch, as I recall, uses a path variable, which does this in a
more standard way.

> > e.g:
> >
> >$ cd ~/bzr-extras
> >$ rsync -aur foo:bzrtools
> >$ ls bzrtools
> >foo.py
> >$ rsync -aur foo:bzrutils
> >$ ls bzrutils
> >bar.py
> >$ bzr help
> >...
> >~  bzr bar
> >~      Do bar.
> >~  bzr foo
> >~      Do foo.
> >
> 
> Well, I would assume 1 layer deep would be what you are asking for, and
> probably don't worry about a "manifest" file, since that makes
> maintenance more than just drop in a file.
> 
> Did you see my earlier post about having a signature line so you don't
> accidentally execute a script that isn't meant to be run by bzr? Is that
> worth anything? What about the whitelist idea? Or if you want to get
> extreme, gpg-signed files, with a whitelist based on author. I think the
> last is unnecessary, but I can think that having a global plugin
> directory for a site would be nice to have, but that you should have
> some sort of trust mechanism, so someone can't pop in a file and
> "bzr help" runs it.

I don't think that needs to be in bzr but you could build it externally.

> And finally, functionality wise having plugins override builtins can be
> very useful. Especially when coupled with per-site plugin directories,
> an administrator can basically setup a policy, and then bzr commit
> follows that for everyone. Is this not worth the potential security
> risks? It seems pretty easy to implement.

That could be useful, if we had 'bzr --builtin commit'.

-- 
Martin