Re: svntar, anybody?

> > - Meaning that every day it's a new set of clients that still have no
> > existing install? if not then this only applies to the first day.
> This is for installation of machines ... a typical linux install has a few
> hundred thousand files, and a few GB of space used.

Thanks, this clarifies the issue quite considerably. None of the
suggested working copy or repository cloning options are going to
perform well.

On either the server machine (or one on a very fast link to the server
machine) use the suggested svntar approach on a daily created tag.
Since you'll have a daily tag you'll not need to retain copies of past
tars since they can be regenerated on demand.

> An update yes; a fresh checkout/export would need to read many revisions --
> perhaps *all* of them, if old data is needed to reconstruct the full-text.
> And this is CPU intensive.

That revision reading will still occur with the svntar approach.
There's no way to avoid the computation during such an activity. You
could very well hit all of the revisions unfortunately since, though
skip-diffs might allow shallow reads in very specific file requests,
broad 'get all files at the HEAD' will likely hit a very wide
distribution of the revisions.

Still, at least it occurs only once for the tar generation.

> > A
> > tar based approach will seek the length of the tar to evaluate
> > differences to sync.
> It won't seek, it will just push that to the clients to apply.
> And linear reading is on the >100MByte/sec range, eg. for a cheap stripe set
> of two harddisks.

Assuming of course that only one client pulls at a time. If not then
you depending upon disk cache to avoid seeking. A large RAM
investment might be coming your way.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org