[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: John Peacock <jpeacock_at_rowman.com>
Date: 2007-07-03 15:36:28 CEST

Ph. Marek wrote:
> I just want a nice, easy, streamlined image of some directory structure ...
> Generated once or a few times a day, sent out without CPU load ...

There are several ways to generate snapshots; I'm not sure what script
the Subversion project recommends, but I've taken over maintenance of


and I could be persuaded to make alterations if that would help you (it
is currently biased towards generating a tarball every time something
changes). It also does it by exporting and tarring the export; I may
consider using something like Archive::TarGzip to streamline that somewhat.

However, every single method of generating an export/dump/whatever from
scratch every time will take much CPU on the server. If you can have a
single working copy on the server that is always in sync with the trunk
(or whatever branch you are distributing), then you could either tar or
otherwise stream that to as many computers as you want daily. If, on
the other hand, the image changes radically from day to day, there is no
other current solution I am aware of that would work.

That being said, I could see using the bindings to read the repository
directly and output something like a tar stream, but that would require
two expertise:

1) using the bindings
2) knowing the tar file format to generate on the fly

Essentially, it would be a matter of writing a recursive cat that
embedded the files into a tar stream on the fly...



John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 3 15:36:21 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.