On Mon, 24 Jan 2005, Ben Collins-Sussman wrote:
>
> On Jan 24, 2005, at 4:19 PM, Peter N. Lundblad wrote:
>
> > I am currently revving the libsvn_repos reporter that gets a report
> > about
> > WC revisions and sends back a tree delta. For locking, it needs to
> > store
> > lock tokens and from the client and senc back lock token removes for
> > defunct locks (for svn up) or just report all locks in the repository
> > (for
> > svn st).
> >
> > My main problem is the latter case. I really don't like the idea of
> > using
> > svn_fs_get_locks for the anchor of the report and pull all the locks of
> > the repository into the server memory at once.
>
> I'm not sure I understand; it sounds like you're objecting to the
> svn_fs_get_locks API itself. You don't like the fact that it returns
> an "all in memory at once" hash of locks?
>
Just to clarify, I am talking about libsvn_repos/reporter.c. It is
streamy (by using a tempfile), so it really seems odd to make it O(n) in
the nubmer of locks.
> If you think that such a thing is non-scalable, then perhaps we should
> change that particular API. Instead of returning a hash, perhaps it
> could call a callback for each lock. (I definitely don't want to stat
> every fs path for a lock!)
>
A callback API wouldn't work here; the reporter needs a pull API. The
reporter already fetches every entry in each directory of the compared
revision, so I think fetching each lock for a directory is reasonable.
Therefore I propose a depth argument for svn_fs_get_locks.
In FSFS, this would be easy to implement (just traverse the children in
the lock entry file recursively but stop on the desired depth).
I think it is possible to do this in the current BDB storage model without
traversing over the whole subtree each time.
So, we have two options as I see it. Either we take the tome now to
implement the above, or we fetch the locks for the whole tree and wait for
scalability bug reports (if any). If we choose the latter, we just need to
make sure that we can add this later if we need. So someone who better
knows the BDB implementation needs to verify that my above assumption is
correct.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 20:56:16 2005