On 03/05/2012 01:57 PM, Stefan Fuhrmann wrote:
On 05.03.2012 15:20, Daniel Shahaf wrote:
Philip Martin wrote on Mon, Mar 05, 2012 at 13:58:18 +0000:
Daniel Shahaf<danie...@elego.de> writes:
Philip Martin wrote on Mon, Mar 05, 2012 at 12:23:40 +0000:
Daniel Shahaf<danie...@elego.de> writes:
You're right, I misread the code: I mistakenly thought line 2867 will
always re-read the revprop-gen file from disk. How about:
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c (revision 1297002)
+++ subversion/libsvn_fs_fs/fs_fs.c (working copy)
@@ -583,8 +583,9 @@ with_some_lock_file(svn_fs_t *fs,
fs_fs_data_t *ffd = fs->fsap_data;
if (ffd->format>= SVN_FS_FS__MIN_PACKED_FORMAT)
SVN_ERR(update_min_unpacked_rev(fs, pool));
SVN_ERR(get_youngest(&ffd->youngest_rev_cache, fs->path,
pool));
+ SVN_ERR(read_revprop_generation(fs, pool));
err = body(baton, subpool);
}
That looks like it works. But it only works if all writers update the
generation file so this whole caching scheme requires an FSFS format
bump to exclude 1.7 and earlier.
+1
(It was pointed on IRC, too.)
If we were to clear the cache after taking the write lock, either
unconditionally or if the revprop generation has changed, then we would
become compatible with pre-1.8 style writers.
Of course this does highlight a change in svn_fs_t behaviour. A long
lived svn_fs_t may never see revprop updates as the cache never expires.
The cached values might get pushed out if the process (thead?) reads
other revisions, to get reasonably up-to-date values the caller must not
hold svn_fs_t objects too long.
Which is a regression --- even a process that does proplist() in a loop
should eventually see changes.
Hm. I would expect the live of a fs_t to be limited
by the life of the RA session. At least for our CL
client, this would not be a problem.
For TSVN dialogs like the repository browser that
keep client contexts open for a long time, it all
hinges on how long the RA session is kept open
by the SVN libs and whether the client has any
control over it.
Can anyone comment on that?
We (Sony Imageworks) have a custom built Subversion server that does
2,000 RPCs/sec, so we LRU cache svn_fs_t, svn_repos_t, and svn_fs_root_t
to avoid filesystem IO.
Blair
