Karl Fogel wrote:
> Blair Zajac <email@example.com> writes:
>> I'm making a svn filesystem network aware using Ice RPC and one of the
>> things I'm running into is that FSFS transactions are not unique. BDB
>> seems to generate transaction names via a sequence, so this isn't an
>> I have the ability for a client to begin a transaction remotely and
>> then refer to that transaction to do work. In FSFS, if a client
>> begins a transaction, gives the transaction name to another process,
>> which then closes it, and a third process begins a new transaction
>> based on the same revision, then it will get the same transaction name
>> and the owner of the original transaction will be operating inside a
>> different transaction and will be able to abort the transaction, which
>> it should not be able to do.
>> So I'd like to make the transaction names unique, using something like
>> "%s-%05ds-%s-%05d" % (apr_gethostname(),
>> where i is incremented until it finds a non-existent directory name.
>> The current transaction name is based off the revision number, is this
>> necessary? Should we keep it? Does changing the transaction name
>> have any other impact?
> +1 on making transaction names unique -- in fact, maybe we
> should take this opportunity to add that as an API promise too. We
> might well add features to Subversion someday that involve the use of
> long-lived transactions.
Regarding the API promise, I think that'll take more work to not reuse
1) Adding the sequence's current value to the svnadmin dump output.
2) Being able to load the sequence's value from a dump into the filesystem.
3) For fsfs, switch from generating the name from current system values
to storing a sequence somewhere.
Given the amount of work, I think we should instead say in the API that
Subversion makes a reasonable effort to generate a brand new transaction
Is it appropriate in svn_fs.h to list the circumstances under which
transaction names may be reused, and list the specific details?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 14 16:29:01 2007