Re: text-base penalty: A proposed solution

On Mon, 2002-12-16 at 07:27, Kean Johnston wrote:
> The documentation sings its praises, and posts from
> previous threads seem to indicate that people place a great deal of
> importance on the ability to edit files on aeroplanes

The prime benefit which motivated the text-base was limiting the network
bandwidth used by commits, as I understand it.

> A software solution should not rely on the *CURRENT* costs of hardware
> in *SOME COUNTRIES* as a means of justifying a solution

Are you saying that hardware is going to get more expensive? It's
possible, but it's not the way to bet. At any rate, in countries where
disk is expensive, bandwidth also tends to be expensive, or so I
understand, so that doesn't really affect the tradeoff.

> Such thinking thwarts innovation, which is usually a prime motivator
> for any software package in the first place.

On the contrary, most of the researchers I've talked to seem to believe
that innovation is easiest when cycle-counting isn't necessary.

> o Thwarts tools like cscope that scan for all source files
> o Makes `find . -name \*.[cCh]|xargs grep SOMETHING` much less useful

We already put a suffix on text-base filenames, so your "find" command
should be unaffected. I'm not sure how cscope works.

> o Doubles the workload of any directory-traversal tools
> o Doubles the inode count (this IS an issue!)

Well, not exactly. It turns out that for every file in the working
directory, there are four in the admin area--text base, props, prop
base, wcprops. We should probably trim this to two (text base and
props+propbase+wcprops), but that still leaves only a 50% inode penalty
from the text base. (Combining the text base with the props is bad
because then you have to rewrite the text base on each propset command.)

All that said, I'd like to eliminate the text base penalty as well. But
here is the fundamental problem with your solution:

  The WC code is already really hairy.

As a consequence:

  * Anything which requires the WC code to behave differently, you'll
have to find the resources for.

  * Anything which requires the WC code to become more complicated (by
giving it N different ways of operating) will probably get vetoed before
1.0.

I've been thinking that the wc library might want to go through a vtable
just like the ra layer does (and like the fs layer is expected to).
Maybe it's too hard to make a single implementation work well for
everyone. I can imagine implementations which:

  * Are just like the current one, with separable subdirs and no
requirement for alerting svn before editing a file.

  * Stash all admin data in some separate location, are not at all
separable, require an alert to svn before editing a file, and support
fast scanning for changes.

  * Are actually repository transactions mounted via NFS or Samba from
an SVN server.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 16:22:34 2002