Revfile vs Atomicity & Dumbfs

[Robert Collins]

On Mon, 2005-05-09 at 19:03 -0500, John A Meinel 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. As Tom Lord pointed out, you really need
> "prepare, committed if x committed, committed". And then future runs
> should check for commit if signaled. Now, if Martin is correct in saying
> that filesystems don't guarantee X is written before Y (even after fsync)

Well. Its true that if you need all the revfiles to have data for all
the same revisions you'd need this. as it happens you dont:

in bzr a revfile is a cache of all the data for a give file id that a
branch knows about. So a commit is roughly:

for fileid in fileids:
  if not textid in revfile(fileid):
    revfile(fileid).add_text (revision_file_changed_in,
                              content_of_file_now)

revfile (inventory_file).add_text (new_revision_id,
                                   current_inventory)

now, all of the above has no impact on clients pulling a specific
revision: its data that would be shown as orphan by a tree linter, but
does no harm.

Then finally, update the revision-history file with new_revision_id and
all that data becomes relevant. So as long as each step in the process
is lossless (not necessarily atomic) and the final step is atomic, then
you are fine.

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

Right. And in fact sftp is easier to provide for some folk than ssh.
(For an example, see http://www.sourcecontrol.net/?action=pushaccount
which is a python sftp implementation).


BTW - great to see you over here ;)

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050510/89e9dcbd/attachment.pgp