[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unique transaction names and revision number (was Re: [PATCH] Remove APR ICONV dependency on Windows)

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2007-07-09 23:18:57 CEST

On Jul 8, 2007, at 4:38 AM, Ivan Zhakov wrote:

> ... And for optimization we removed revision number from txn name.
> So we got "<hostname>-<pid>-<time>-<uniquifier>" txn names.
>
> Looks good, but bad news that this form of txn names isn't guarantee
> to be unique. ...

So, I guess the <uniquifier> isn't unique enough... :-)

On Jul 9, 2007, at 12:20 PM, Blair Zajac wrote:
> Ivan Zhakov wrote:
>> On 7/9/07, Blair Zajac <blair@orcaware.com> wrote:
>>> Ivan Zhakov wrote:
>>> > And we are fail because fsfs assumes that transaction names unique
>>> > between revisions! So it MUST include revision number.
>>> >
>>> > So we have to problems:
>>> > 1. transaction names still isn't guaranteed to be unique
>>> > 2. fsfs depends that transaction names unique between
>>> revisions, i.e.
>>> > include revision number.
>
> Actually, this won't fix the problem if you have two transaction
> started on the same revision.

Sometimes for problems like this where there's a small, but not small
enough, window of opportunity for collision, I've found it useful to
make the window vanishingly small by using a random-number
uniquifier. Assuming (and maybe it is too much to assume on all the
systems that Subversion supports via APR), that there's pseudo-rng
such as /dev/urandom or equivalent available, then that might be
enough to ensure the absence of collisions for practical purposes.

-Travis

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 9 23:18:57 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.