[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: lock scalability

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-03-15 04:50:54 CET

On Mar 14, 2005, at 6:24 PM, Garrett Rooney wrote:

> Brian W. Fitzpatrick wrote:
>> On Mar 14, 2005, at 2:06 PM, Garrett Rooney wrote:
>>> Ben Collins-Sussman wrote:
>>>
>>>> Given that svn_repos_fs_(un)lock() will probably -- eventually --
>>>> be receiving a whole list of locks from the network, cmpilato and I
>>>> are wondering if it makes sense to define the post-(un)lock hooks
>>>> as taking a list of paths *right now*, rather than one path. If
>>>> somebody decides to lock 5000 things at once, it's important to get
>>>> one email, not 5000 of them.
>>>
>>>
>>> Make sure to pass the list via STDIN or something, rather than ARGV,
>>> you don't want to hit arbitrary limits on the number of arguments
>>> that can be passed to a program.
>> Good point. I'm going to get started on revising the post-(un)lock
>> hooks to read locked paths from STDIN. I figure that it will be safe
>> to separate each path by a newline.
>
> Yeah, we're already assuming paths can't have newlines in them in
> other places (dumpfile format, for example), so it's not like it can
> really hurt to do it here.

*nod*

Before I start hacking up libsvn_repos, did anyone have any
implementation thoughts WRT this change? fs_wrap.c has
svn_repos_fs_lock, and it takes a single path in, calls the pre-lock
hooks, does the lock, and then calls the post-lock hook. Now I don't
see any unobtrusive way to call the post-lock hook here, but maybe I'm
missing something.

Anyone?

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 15 04:52:14 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.