Revfile vs Atomicity & Dumbfs

Aaron Bentley aaron.bentley at utoronto.ca
Tue May 10 01:51:52 BST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
| Aaron Bentley wrote:
|
|> Actually, revfiles can easily be done in a transaction-safe way, because
|> as Martin explained to me, appending to the text-contents file is
|> essentially a no-op until you rewrite the indices.  And rewriting the
|> indices can be made atomic using the standard write-to-temp,
|> rename-to-final technique.
|
|
| Except if you are rewriting 10 different files, then you have to make
| them all go "pop" at the same time.

True.  Here's how that works with revfiles:
1. For each revfile
~   a. Append to the revfile text
~   b. rewrite the revfile index
2. write the inventory for the revision
3. append the revision to the revision history.

Stages 1 and 2 don't matter, because until 3 is done, the revision has
nothing to do with the current tree, or indeed any other tree.  Also,
you can add anything you like to a revfile, without causing any problems
now or later.

|> 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
|
|
| But if you
| have to have a server for write access, you don't have a dumbfs.

That's what he's saying there; perhaps for writing, it is reasonable to
require more than a dumbfs.

|> Write-ahead logging would also be nice for operations like merging that
|> are necessarily non-atomic.

| Well, if you wanted to make merging a little bit more atomic, you can do
| merging into temp files, and use the same multi-stage commit. But with
| that you still get bogus files lying around, but in theory the next run
| of bzr (or maybe bzr fix), should clean up after itself.

It's not just the diff3 that's an issue.  (Though I do write that to a
temp file.)  Doing renames/creates/deletes requires files to be moved to
temporary locations.

The canonical example would be;
foo -> bar
bar -> foo

If I lose power between renaming the files to temp names and renaming
them to final names, I'd like to be able to restore the directory.

| It depends what you want merge to do, though. For a conflict, it seems
| like you should keep going and mark the file conflicted. If the program
| dies in the middle

I agree about conflicts.  I meant it would be nice for 'dies in the
middle'.  And possibly for exception handling.

|> That would be cool.  I'd like it to be a directory of directories, so
|> that you can have commands from multiple sources.  e.g:
|>
|
| Well, I would assume 1 layer deep would be what you are asking for,

Yep.

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

You can just use a different file extension.  I nominate ".bzp".  That
way, you don't have to read the file in order to find out whether it's a
plugin.

| 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 see how that's a different from the risk that someone can stick
a file in ~/bin.  Unless you did something silly, like making the dir 0777.

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

I'd say it's worth it.  Especially, it would make it trivial to add
hooks to a command.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgAWo0F+nu1YWqI0RAqseAJ9/1ZILEymEi41VbqJdReRpKzXIAACfRkbN
lBue9fP8OTdIVFjhguQHgF8=
=SQwI
-----END PGP SIGNATURE-----




More information about the bazaar mailing list