[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-03-23 08:50:55 CET

On Tue, 22 Mar 2005, Ben Collins-Sussman wrote:

> On Mar 22, 2005, at 5:06 PM, Philip Martin wrote:
> > Ben Collins-Sussman <sussman@collab.net> writes:
> >
> >> We've added three (const char *) fields and one apr_time_t to the
> >> entry structure.
> >>
> >> If we assume that most files will be unlocked most of the time, then
> >> those four new fields will almost always be NULL. This will still be
> >> a 20% memory increase?
> >
> > Yes. The svn_wc_entry_t structure itself has increased from 104 bytes
> > to 124 bytes on my Linux box (3 x const char * == 3 x 4 bytes,
> > apr_time_t == 8 bytes, 20 bytes total).
> >
> 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?

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 being said, there is no excuse for wasting memory. The reason I
didn't add an svn_lock_t* is that the path field (the absolute FS path) is
not available. I didn't cache that in the entries file, since it can be
derived when we have repos_root stored there. but if we think the extra
memory use is a problem, it is not very hard to change this to store an
svn_lock_t*. We could document that the path will always be null.

(Note that this discussion is relevant regardless how we store this in the
entries cache.)


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