I have taken users@subversion.tigris.org off the cc list, because this
conversation has no end-user content. In general, cross-posting between
dev and users doesn't seem like a good idea to me.
The access patterns for the .svn administrative area do not seem to make
sense for storing the whole bundle in one file. Let me draw up an
example:
Suppose I have a directory with a hundred roughly 100K files, named f000
through f999. I do "svn update", and files f100, f400, and f700 have
had updates... let's say, additions on the order of 10K. How do we
update the base texts? The answer depends on how the .svn area is
represented:
* If the .svn-replacement file simply holds the compressed
concatenation of all the base texts, then the entire file (at 10MB,
pre-compression) needs to be rewritten. That's very inefficient,
regardless of whether the processor can keep up with the compression
algorithm.
* If the .svn-replacement file holds the individually compressed plain
texts, then it may be possible to write out just the three new
plaintexts (compressed), and then garbage-collect the blocks used by the
old plain texts. But now the code which manages the plain texts needs
to contain a complete filesystem implementation, complete with locking.
Even assuming there exists some suitable library which accomplishes this
(which has to work on Unix, work well over remote filesystems, and so
forth), that's a huge dependency. I don't see how you can call this a
"low-cost solution."
Moreover, this proposed change seems totally orthogonal to fixing the
asp.net problem. We could put the entire administrative area in a file
(rather than a directory) named .svn, and Visual Studio would remain
broken (until Microsoft fixes it, which is actually expected to happen
in the next release). We could move the administrative area to a
directory with a different name, and Visual Studio would no longer have
a problem. We aren't likely to do either, though.
Finally, proposing design changes without any understanding of the
existing code is a bit over the line. "It probably wouldn't
significantly change more than a few lines of code" is simply untrue; it
would require rewriting a great deal of libsvn_wc, which clocks in at
18,500 lines of code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 21:36:26 2004