John Pybus <john.pybus@zoology.oxford.ac.uk> writes:
> > Only if people *are* getting bitten by this :-). We should first make
> > sure that this effect isn't lost in the noise of other things.
>
> Reading the svn lists, people converting from CVS seem to think
> so. This would be because they will come in with long-lived
> repositories containing real examples of branch usage over time (of
> which there must be relatively few with SVN so far?), and because they
> have a definite size to compare to. People starting new projects, or
> not trying to import old history, wouldn't be expected to notice for
> some time, and having no hard number to compare wouldn't notice so
> strongly. (I'm ignoring all the cvs2svn inefficiency discussions)
Let's be careful:
People converting from CVS are noticing larger repositories. Whether
those large repositories are due to this, or to something else, or to
some combination of factors, is an open question.
> Surely having some exploration of the space of possible branch
> strategies, and the disk usage associated with it, will be more
> informative than none. Though clearly the usual warnings about
> synthetic benchmarking would apply.
Yes. (Who would disagree with that? :-) )
> If in case iii) the cost of accessing old nodes shared with trunk is
> acceptable, what is the benefit of storing fulltexts for the changed
> nodes even on long lived branches? On short lived branches, the cost
> of fulltexts born even when the branch is no longer required seem no
> more sensible.
That's an excellent question.
The answer, I think, is simply that this was the way things fell out
in the most obvious implementation. In other words, we didn't do
anything special to get this behavior, we simply use the same
deltification policy for all paths. If we were to change it, we would
probably be making the libsvn_fs code more complex (which is why I
don't want to do it without clear stats indicating that we need to).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 20:27:28 2004