Karl Fogel wrote:
> Blair Zajac <blair@orcaware.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
>> issue.
>>
>> 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(),
>> apr_uid_current(),
>> apr_time_now(),
>> i)
>>
>> 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
transaction names:
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
name.
Is it appropriate in svn_fs.h to list the circumstances under which
transaction names may be reused, and list the specific details?
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 14 16:29:01 2007