[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svntar, anybody?

From: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2007-07-04 08:15:55 CEST

On Mittwoch, 4. Juli 2007, Talden wrote:
> > I want to push some (big) amount of files as fast as possible to a number
> > of clients, which have no prior version available as they're freshly
> > installed.
> - 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.

> - Big AMOUNT of files or BIG files? And define big... 100,000 files
> of 150kb or 100 files of 150mb.
Both :-) Some files are big, most are small ...

> Also, clearly, working copies or repo clones are out of the question
> if they don't have the space to keep a duplicate copy. Working copies
> have pristine copies and the repo clone option is, by definition, a
> duplicate since you need to extract content from the clone.
Once again, the clients should get a snapshot.
Having ".svn" is not possible (space wasted, perhaps a security problem), and
a complete repository even more so.

> You want to avoid seeking and I assume this is at the server end.
Right.
> A
> working copy update would only be seeking the last few revisions.
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.

> 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.

Please note that the tar file is just a kind of cache, nothing more!

Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 08:16:01 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.