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

Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-11-28 12:58:58 CET

On Mon, Nov 28, 2005 at 11:25:23AM +0000, Julian Foad wrote:
> Malcolm Rowe wrote:
> >On Mon, Nov 28, 2005 at 09:59:06AM +0100, Ph. Marek wrote:
> >
> >>- space on harddisk - this is *currently* important! A wc with 1000 files
> >> with no properties other than svn:text-time on a 4kB filesystem needs
> >> 1000 * 2 * 4k ~ about 8MByte *only for this properties*!
> >> Now go to a wc with 100000 files ... and 800M are gone.
> You say "800M are gone" as if it's a bad thing, but if the whole WC
> occupies 10 GB or so then it's trivial.

Sure. The Subversion trunk is 2000 files in 50~60M, so an extra 16M
(~25%) would be a pain, though not particularly significant. Users of
the gcc repository might disagree, but I suspect they're not planning
to use this feature anyway.

Note that I originally misread Philipp's note as 'a wc with 1000 files
... and 800M are gone', which _would_ have been quite a big deal,
premature optimisation or no. Now that I re-read it, I see he was
talking about a significantly smaller overhead than I first realised.

> You're both doing "premature optimisation". Concentrate on what would be
> functionally desirable, and THEN determine if we need to make any
> improvementes in efficiency, and we'll make them. Mention the inefficiency
> as a caveat, don't treat it as a show-stopper.

Yes, absolutely - and that was what I intended. We should consider the
impact, and make sure we don't do anything truly stupid, but that's all.

> >[Note that the FSFS format has the capability to store properties as
> >deltas against earlier versions, but the implementation doesn't currently
> >do that, presumably at least partly because properties are considered to
> >be things that change infrequently - and so doing so probably wouldn't
> >be worth the effort in terms of space saved, and would also mean it
> Looks like you got your argument back to front there :-)

ITYM 'guess' rather than argument. I've no real knowledge as to why
the FSFS implementation doesn't produce deltas for properties.

> >would take longer to reconstruct the properties during a read.]
> Premature optimisation again - unless you have measured that speed loss and
> found it to be unacceptably large, which I seriously doubt.

No, not premature optimisation this time: it _would_ take longer to
reconstruct the properties if they were stored as deltas.

Whether it would take significantly longer is something we'd have to
measure later, though only if we first decided that the overhead from
rewriting the properties each revision meant that we should deltify the
properties too ... and we'd have to measure that too :-)

(I think we're in agreement, though perhaps I need to work on my
communication skills)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 28 13:04:08 2005

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

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