Blair Zajac wrote:
>
> On Jun 16, 2007, at 2:28 PM, Blair Zajac wrote:
>
>> Daniel Berlin wrote:
>>> On 6/13/07, Blair Zajac <blair@orcaware.com> wrote:
>>>> 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.
>>> apr-util has apr_uuid_get to get new UUID's, and apr_uuid_format to
>>> turn them into strings.
>>> Is there some reason you can't use it?
>>> Otherwise, I was going to suggest this myself as part of a design i'm
>>> working on for 2.0's merge tracking.
>>
>> No, wasn't aware that apr had a uuid method. We could switch over.
>> In fact, making BDB and FSFS use uuid's would be nice.
>
> BTW, if we do switch BDB over to use uuid's, then I believe code will
> have to be written to check if a BDB transaction name is already used.
> Now, since there's a sequence, it can assume that the transaction name
> will be fresh.
We have no compelling reason to change BDB at all, so I'm -1 on doing so.
As transaction names wind up being stored as part of the node-revision-id
triplet, I wouldn't want to start seeing nodes like
'4uv.3e.22006a41-a1fb-0310-bd7e-c51a55d5d677'. That BDB transaction IDs are
sequential base-36 numbers has, on more than one occasion, assisted me in
debugging a BDB-backed repository.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon Jun 18 15:57:53 2007