"Peter N. Lundblad" <peter@famlundblad.se> writes:
> > - Put dir-props and dir-prop-base into entries as well.
>This is normally just one extra file per directory. It will mean that
>we will have to read and rewrite the dirprops every time we want to
>update the entries file. NOte that the working props file is gone in
>1.4 unless there actually *are* property modifications. The same
>holds for files.
It is admittedly a minor issue, but since the dirprops are typically
very small this should be no extra overhead.
> > - Combine all prop-files into one single file: [...]
>Two files is no noe, so the situation has improved. The problem with
s/is no noe/are no more/ ?
>combining all props into one file is that changing one property will
>mean that we rewrite all properties just to set one property, which
>might be a problem if you use large properties.
No, properties are _never_ large in practice; Subversion just isn't
used that way. I'm not advocating any artificial restrictions - users
can stuff gigabytes in their properties for all I care - but
optimising for the not merely uncommon but completely _nonexisting_
case is just bad engineering.
This came up some while ago when discussing whether MacOS resource
forks should be stored in properties, and the consensus was that it
was a Bad Idea for several reasons, size being one.
On the other hand, _small_ properties are not uncommon at all, which
makes the practice of putting them each in their own file(s) all the
more wasteful - 100 versioned files will easily eat 800 K just in
properties, no matter how small.
> I've been thinking of
>a compromise where you store the base props in one file (with some
>lookup table so you don't have to read the whole file to get one
>property) and then store working props in individual files when there
>are property mods. That's not going to happen for 1.4, though.
This sounds sensible.
> > - Use file locking instead of lock files. [...]
>[...]You need to keep a lock file open for each directory
>which might well exceed the per-process limit for maximum number of
>ope files. If we switch to a scheme where you lock the whole working
>copy, this will not be a performance problem anymore:-)
Agreed, locking the whole WC is by far preferable.
I profiled svn status/update to find out why it was so slow on NFS, and
the lock files stood out as an obvious problem (and NFS traffic confirmed
this), and especially on Solaris whose NFS implementation is more
protocol dogmatic (less caching) than Linux's.
> > - Combine all the .svn directories to one single directory in the
> > root of the WC. [...]
>This makes it impossible to move parts of a working copy to another
>place. I don't say this is the most important feature in the world (I
>don't know how many people actually use it), but it is a rather
>disruptive change.
I wasn't even aware of the possibility, and frankly I don't think it's
important at all (but would happily be corrected).
> > - If the user explicitly asks for it, hardlinked text-base files.
>This isn't portable and it is dangerous. I'd much more like optional
>text bases to be implemented.
Don't discount it that easily, it's more portable than you think.
Hard links are available in OS X and even NTFS nowadays. Dangerous,
not really - as I wrote, corrupted text-base would easily be detected,
and besides it would never be the default but an active user choice
(svn co --I-promise-to-break-links-on-editing). All standard editors
do the right thing by default.
Optional text bases are nice but slower and won't work when disconnected.
> > - Remove README.txt and empty-file.
>Done in 1.4.
Yay!
Thanks for the insightful reply. I realise a more thorough WC metadata
reform is a bit further ahead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 8 13:03:09 2006