Revfile vs Atomicity & Dumbfs

[John A Meinel]

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, it's certainly
> better than write anywhere, but new-file only works better with backups,
> 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).
...

I wanted to add this comment from "bzr.dev/doc/formats.txt":

   These files are designed so that repository-level operations are ACID
   without depending on atomic operations spanning multiple files.  There
   are two particular cases: aborting a transaction in the middle, and
   contention from multiple processes.  We also need to be careful to
   flush files to disk at appropriate points; even this may not be
   totally safe if the filesystem does not guarantee ordering between
   multiple file changes, so we need to be sure to roll back.

   The design must also be such that the directory can simply be copied
   and that hardlinked directories will work.  (So we must always replace
   files, never just append.)


I don't know if this design decision has changed. Or if the plan is to
move it out of the way, copy it back, and then append, but it does break
this rule.

Although, I think the clone-and-replace method gets around this, since
it already has to break hardlinks, but would preserve ones that haven't
changed.

Though I would guess hardlinks are much less portable than truncate.
Because I know FAT doesn't support hardlinks, I don't explicitly know of
any systems that don't support truncate.

Also, it might be decent to have multiple methods, so that we can fall
back on something when the OS doesn't support the faster version.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050509/c5c97b9f/attachment.pgp