Revfile vs Atomicity & Dumbfs
aaron.bentley at utoronto.ca
Tue May 10 01:51:52 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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"
| 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
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,
| 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
| 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar