> -----Original Message-----
> From: Stefan Küng [mailto:tortoisesvn_at_gmail.com]
> Sent: maandag 2 augustus 2010 21:52
> To: Bert Huijben
> Cc: 'Subversion Development'
> Subject: Re: Need fast ways to get Info once WC-NG is introduced
> On 02.08.2010 12:32, Bert Huijben wrote:
> > I don't think there is a specific per folder check like this, but
> > specific data about just one node (instead of its folder) will be
> > faster than in the old entries store. With the entries files we had
> to read
> > the entire file in all cases, but a real database doesn't have that
> > limitation.
> > For all metadata except for pristine files we only have to open one
> file and
> > sqlite just seeks to the right locations to fetch the data using its
> > indexes.
> > For AnkhSVN I'm thinking about splitting the status cache in two
> > instead of doing a 'svn status' per folder like we do in 1.6. (I
> > TortoiseSVN might do the same thing, but maybe it calls status with
> > infinity)
> Yes, TSVN does the same: one 'svn st' per folder with depth immediate.
> > Getting information from the working copy per individual file will be
> > much cheaper than before, that I will look for metadata changes first
> > cache only a fraction of the informational details I used to cache
> > and only when I really need to, I will perform the pristine file
> > (I don't know yet if I will use svn_(client|wc)_status for this or by
> > calling svn_wc_text_modified_p2() myself).
> > I would imagine that TortoiseSVN's folder glyph status would be
> > much faster by using a similar strategy: First check if there is a
> > change or conflict somewhere in the tree (keeping track of translated
> > filesize + filedate as these will be useful in the next step).
> > (This would be +- svn_client_infoX(). This should also inform you of
> > property changes (I don't know if it already does that; but the
> > in our internal API's is there now))
> > If there is such a status: just set the right glyph (early out; no
> need to
> > check any pristine files)
> So basically use svn_client_info() instead of svn_client_status(), then
> only check the status for files that don't have a defined status yet
> from that info. That seems like a good idea - a lot of work to rewrite
> the existing code, but it should be worth it.
> > And only if there isn't a status perform the
> svn_wc_text_modified_p2() calls
> > where needed.
> Would this API get renamed to svn_client_*? Or should I risk calling an
> svn_wc_ API? It's still not clear whether the svn_wc_ APIs will get
> private as was discussed before.
Personally I don't see a problem with calling a wc api for this task. (It
has the same version guarantees as the client apis: we can't break this
before 2.0). Of course we can also add a wrapper in the client layer, but in
this case that would be just a one-on-one wrapper. (You can get the wc_ctx
from the svn_client_ctx_t). But we would have to maintain both until 2.0.
If you know exactly what you need for your cache, I would prefer adding a
few helpers for that task in libsvn_client over adding exact copies of the
Other system or applications integrations like SCPlugin, KSvn and AnkhSVN
will face the same issues and would want to use these same helper apis.
> I thought about implementing a small cache for that, so that I don't
> have to walk up the tree every time to find an .svn dir.
> But I thought I read something about such a small cache getting
> implemented in the svn library itself so I wanted to ask first - maybe
> there's already an API to use that cache. Or maybe I just remember it
Yes, the wc_db api has a cache for this, but it has two issues that would
make me avoid it in TortoiseSVN:
* It sees every directory below a working copy as part of the working copy.
(So it is just like keeping a cache of the top level databases. Probably
not the answer you were looking for)
* And it keeps an sqlite database handle open for you.
If keeping the sqlite handle open is not an issue to you, I would recommend
keeping it open as long as possible. But with that handle open you can't
just delete a working copy by removing its files.
(I have some ideas on how we might fix that in a Windows specific way on
Vista+ using oplocks, but that will take quite some research and building
our own filesystem-layer for SQLite.)
Received on 2010-08-04 10:38:21 CEST