bzr too slow

[Robert Collins]

On Thu, 2006-01-12 at 02:24 +0100, Denys Duchier wrote:
> Martin Pool <mbp at sourcefrog.net> writes:
> 
> > Right, and you could possibly also have "rollback tasks", which are run
> > if the transaction is cleaned up without being committed.
> 
> My own approach to this issue is basically the TransactionFS that I posted about
> earlier.
> 
> The TransactionFS by itself does not guarantee that committing it will succeed
> (perhaps things have changed concurrently, or perhaps you are exceeding your
> quota, or perhaps you have rights, but the filesystem is so mounted that you
> cannot exercise them (might happend e.g. with poetzl's bme, etc...)).
> 
> If really desired, a robust form of journaling can be implemented that addresses
> these issues, but that's a lot of work for basically NO reward (considering that
> "bzr revert" can fix most practical cases).

There are two broad areas here - local disk access and remote access.

I think TransactionFS as an approach is fine for local disk tasks, but I
dont get the impression that its suitable for use with our transports
that deal with sftp etc - where the link may go away at *any point* -
that is, we must maintain a valid uncorrupt repository/branch no matter
what stage the tcp etc link disappears.

Some background here - the Transaction class in bzrlib refers to a
single unit of work, its an aid for controlling the amount of domain
objects instantiated and grouping the related domain objects of a single
unit of work into one, well, group. Its not an implementation of an ACID
journal or anything like that - and its not meant to be - it depends on
the underlying serialisation methods used by the library to provide
that.

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/20060112/848208b8/attachment.pgp