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.
> Although matters are progressing on this front.
That's quite significant. Also, files do not typically have properties
(with the possible exception of svn:eol-style), and there's a fair amount
of optimisation that's been done lately to improve matters in that case.
Adding svn:text-time to all files unconditionally would probably be a
bad idea.
> - with the current patches there's a chance of conflicts in the property.
> If I dig out the old version and look there this could be avoided - there
> was a special case to take the newer of two dates.
>
Conflict resolution should be specified in the design. Like Julian said,
it should be possible to infer the behaviour that's expected after any
combination of steps.
> BTW, a question just pops up in my head: if a property's name is used for many
> files, is the name in the repository just stored once, with pointers to it,
> or are there N copies?
>
I don't know about BDB, but for FSFS, there's a complete (uncompressed)
copy of the property hash stored in the rev-file whenever any of the
properties changes.
So for N files, each with M revisions, you'll have N*M copies of the
whole property hash (since we'd expect the mtime to change on each
commit).
[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
would take longer to reconstruct the properties during a read.]
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 11:41:15 2005