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.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 24 16:30:38 2006