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

Re: FSFS safety violation caught by testing? (r34197)

From: Blair Zajac <blair_at_orcaware.com>
Date: Fri, 14 Nov 2008 21:37:43 -0800

On Nov 14, 2008, at 7:53 PM, C. Michael Pilato wrote:

> C. Michael Pilato wrote:
>> C. Michael Pilato wrote:
>>> David Glasser wrote:
>>>> Anyway, I think the transaction name algorithm changed in 1.5;
>>>> check
>>>> libsvn_fs_fs/structure for details.
>> Hrm. Interestingly, the test doesn't care about naming schemes.
>> It creates
>> a bunch of transactions, remembers their names, and aborts them
>> all. The it
>> does it again to see if any of the transaction names got reused.
>> I'll look
>> into this a little bit more closely.
> Well, we have a decision to make. If we think it's a bug that
> transaction
> names can be reused, then FSFS repositories created with Subversion
> 1.4 have
> this bug. I don't understand that ramifications of txn reuse (which
> is why
> I've Cc: Blair -- I remember this topic coming up on the list and
> being
> driven by him).
> If we'd rather ignore the problem, it's easy enough to make the code
> bail
> out when testing FSFS with 1.4-era repository versions. I'm happy
> to make
> that change -- just let me know.

I put this feature in to support my svn_fs.h and svn_repos.h RPC API.
I found that when you had a client begin a transaction and another one
use it, then the first one close it and begin another one, the second
client would not know that it was not using the original any more (it
should have received a txn does not exist error instead).

I don't need this feature in 1.4, so having txn ids be non-unique in
1.4 is fine with me.


Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
Subversion training, consulting and support
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-15 06:38:00 CET

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.