lock-breaking ui

[John Arbash Meinel]

Jan Hudec wrote:

...

>> Therefore perhaps we do just have to assume that you only break a lock
>> if you really are sure no one else holds it.  This is not perfect, but
>> only the same requirement as cvs and svn (and arch?)
> 
> No. Arch had correct transactions - you could force a rollback and it did not
> screw anything.
> 
> For that matter AFAIK subversion's fsfs does as well -- though that is never
> accessed over ftp or sftp, so it's a bit simpler.
> 
> 
> I was actually thinking that perhaps keeping some log in the lock would help.
> In that the client who breaks the lock would know which files were written,
> or about to be written, by the client who held the lock, and could clean (or
> even be required to) up a bit.
> 

Right, Arch did have the transaction that you can break a lock someone
else holds, and the other person's changes are lost.

I think I mentioned having a write-ahead log. My only concern is the
latency it might introduce. Since to be fully transactional, you need to
wait for it to be physically written (equivalent of fsync on a local
system).

If we can queue up things and say "I'm going to be changing these 50
files, they are the ones that need to be fixed if I fail", then I'm okay
with it. But if we end up doing:

  I'm changing X
  sync log
  change X
  I'm changing Y
  sync log
  change Y
  I'm changing Z
  sync log
  change Z

That would vastly increase our round trip latency. Since to be safe we
can't pipeline anything.

I kind of like having "I'm adding revision X, which will effect files
A,B,C,D"

I was thinking that then at the time you break the lock, you could check
those files and clean them. But you can't, since breaking the lock means
that you aren't sure if the other process is still alive and making
changes or not. You have to wait until you are sure that the other
process is done before you can clean anything.

Now you could set a 'possibly-contaminated' flag on those files. Or if
the other process notices that it lost the lock, it could set the flag.
The problem is that you have a race condition of "process A grabs the
lock, starts making changes, process B breaks the lock, process A keeps
changing things, process A loses connectivity before even trying to unlock".
Now there is no process A to notice that it was unable to unlock, and
mark things as conflicted, even though it *did* contaminate some files.

So I don't see a huge benefit from all the complexity. You get a little
bit of benefit, but you don't completely solve the problem. And you add
a lot of complexity.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060223/7d4d09f3/attachment.pgp