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

Re: Making fsfs generate unique transaction names

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-06-14 06:31:43 CEST

C. Michael Pilato wrote:
> Blair Zajac wrote:
>> After looking at this, I'm wondering if maybe we should use sqlite to
>> store a sequence value in it and use the same key incrementing approach
>> that the BDB backend uses to generate transaction names. The current
>> value of this sequence would be dumped along with the repository and
>> imported, thereby preventing the reuse of a transaction name. I believe
>> that if you dump and load a BDB transaction, then currently, sequence is
>> reset.
>> Using sqlite would be more work, since I'd have to familiarize myself
>> with it, but it may be a cleaner way to go.
>> If we did go that way, would we drop the key generation from the BDB
>> tables?
> I'll not be excited about any attempts to make our already-a-database
> backend more of a hybrid-of-multiple-databases backend. The shared code
> benefit simply doesn't outweigh the mental hoop jumping required to
> understand why some data is stored in one database and the rest in another.
> Besides, all the nice atomicity guarantees of BDB break down when you've
> got to interact with a non-BDB data store, too. If it's not obvious, I'm
> already bummed that we're using sqlite in the BDB backend, but I think it's
> too late to try to remedy that at this point.

Well, maybe we should put everything in Sqlite :)

Seriously, given your comment, I'll put the commit in to at least make
FSFS transactions less likely to be reused.

To the point about atomicity, agreed in general, but for generating a
transaction name, there's no issue. If you end up burning a sequence
value to generate a transaction name and need to roll something back, no
big deal.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 14 06:31:56 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.