Mattias Engdegård 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.
> - Combine all prop-files into one single file: Any file with properties will
> take a full disk block for each prop-file (two per file), in addition to
> the inodes (which are not free either, contrary to common belief).
> And it gets even worse when running SELinux[*].
Two files is no noe, so the situation has improved. The problem with
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. 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.
> - Use file locking instead of lock files. This should be considerably faster,
> especially over network file systems, and will not leave locks hanging if
> a crash occurs. (It won't work on NFSv2, but nor do plain lock files without
> a little bizarre dance with link() and stat() which isn't done today.)
Problematic with the current scheme where you can lock individual
directories. 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:-)
> - Combine all the .svn directories to one single directory in the root of the
> WC. This could avoid several recursive traversals entirely, and need fewer
> locks. Users would be happy too (no .svn/ dirs everywhere).
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.
> - If the user explicitly asks for it, hardlinked text-base files.
> Most editors will break the links on editing, and disk usage would be
> almost halved. Inadvertent corruption of the text-base could be detected.
> Checkout performance would be much improved as it's mostly I/O bound.
> Comparing a file against its hard-link costs zero syscalls if the inodes
> (from the readdir) are the same.
This isn't portable and it is dangerous. I'd much more like optional
text bases to be implemented.
> - Remove README.txt and empty-file.
>
Done in 1.4.
Some of the ideas I dispute above are good, but not feasible
currently. If/when we rewrite the working copy library (or part of
it), I think we should consider a completely different way of storing
working copy metadataa. What I am trying to do now, is to improve the
current design while keeping its current feature set.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 7 22:13:35 2006