Daniel Berlin wrote:
> Branko C(ibej wrote:
>
>> Masaru Tsuchiyama wrote:
>>
>>> Index: subversion/libsvn_fs_fs/tree.c
>>> ===================================================================
>>> --- subversion/libsvn_fs_fs/tree.c (revision 20833)
>>> +++ subversion/libsvn_fs_fs/tree.c (working copy)
>>> @@ -1102,7 +1102,7 @@
>>> apr_pool_t *pool)
>>> {
>>> sqlite3_stmt *stmt;
>>> - long long int lastchanged_rev;
>>> + apr_int64_t lastchanged_rev;
>>> int sqlite_result;
>>>
>>> SQLITE_ERR(sqlite3_prepare(db, "SELECT MAX(revision) from mergeinfo_changed"
>>> @@ -1228,7 +1228,7 @@
>>> apr_hash_t *cacheresult;
>>> sqlite3_stmt *stmt;
>>> int sqlite_result;
>>> - long long int count;
>>> + apr_int64_t count;
>>> svn_boolean_t has_no_mergeinfo = FALSE;
>>>
>>> cacheresult = apr_hash_get(cache, path, APR_HASH_KEY_STRING);
>>>
>>>
>> Now I see we're using sqlite in fsfs. Interesting.
>> http://www.sqlite.org/lockingv3.html states explicitly that sqlite
>> databases aren't stable over NFS.
>>
>
> No, it explicitly states that it doesn't work if your NFS locking is buggy.
>
>> Doesn't that somehow subvert the whole
>> idea point of using fsfs in the first place?
>>
>
> I've been through this before.
>
> It works perfectly fine (I've very heavily load tested it) on servers
> that support nfs locking properly. This includes windows nt, linux,
> solaris, etc.
>
> If your locking is buggy, you were probably fucked anyway.
>
> If you want to reimplement the indexing, have fun!
>
> Otherwise, i'm not going to argue about whether we should change the
> entire underlying indexing layer to work on systems that are very buggy.
>
All right ... but, doesn't more or less the same argument hold for BDB
over NFS?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 24 20:55:34 2006