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.
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 06:31:56 2007