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

Re: Locking branch has been merged [Re: svn commit: r13571]

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-03-23 19:47:24 CET

"Peter N. Lundblad" <peter@famlundblad.se> writes:

> On Tue, 22 Mar 2005, Ben Collins-Sussman wrote:
>> Okay, maybe lundblad can refresh my memory here. I'm looking at
>> svn_wc_entry_t, and I'm wondering why it's storing anything more than a
>> token-field. That's the only critical bit of authentication the
>> working copy needs to make use of a lock. Why do we have the entire
>> (potentially multi-line) lock-comment being cached in the entries file?
> How would you implement svn info wcpath without it?

I guess your assuming "svn info wcpath" must display all that lock
info. Perhaps "svn info wcpath" should only display the lock token,
as the only thing cached in the wc, and there would be some flag (-u?)
to get more info from the repository.

> Regarding the size increase, I think these 20% aren't true. The struct is
> 20% bigger, but considering that wvery entry struct has a copy of the
> whole URL (and also has other fields allocated), the total memory usage of
> the entry is not increased by 20%.

That's more or less what I wrote in my first email. On a wc with
50000 entries (I think a gcc wc will have over 30000 entries) the
client will use an additional 1MB caching the entries even if there
are no locks.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 23 19:48:51 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.