Revfile vs Atomicity & Dumbfs

[Aaron Bentley]

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

John A Meinel wrote:

| Right now, I think you are just keeping a complete copy of each revision
| of a file, which you obviously don't want to do over time. The current
| suggestion is to use the "revfile" method, which has an append-only
| index and an append-only text store.
|
| The thing is, append-only isn't very transaction safe,

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.

| 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

| (I suppose you could do sequential compressed streams in one
| file, though too).

"sequential compressed streams in one file" sounds a lot like revfiles.

| I also thought about atomicity, and I thought about two basic methods,
| WAL (write-ahead logging), and clone and replace. Basically, wal would
| be something like .bzr-transaction-log which would include what has
| occurred with the tree, when the final commit occurs, the file could be
| deleted. Clone-and-replace is basically, copy everything from .bzr to
| .bzr-new, make modifications to .bzr-new, and then
| rm -rf .bzr
| mv .bzr-new .bzr

Write-ahead logging would also be nice for operations like merging that
are necessarily non-atomic.  If a merge is interrupted, you'll wind up
with junk dirs all over your tree.  You can revert, of course, but
reversing a log seems cleaner.

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


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

iD8DBQFCf/J90F+nu1YWqI0RAiLSAJwIByjyYPtz01RD2enC1gSEfb68sACeOcrb
mdZnOvEwzxonInTg7uniM78=
=MNX1
-----END PGP SIGNATURE-----