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

RE: Very esoteric problem

From: Campbell, Matthew A <Matthew.Campbell_at_Relizon.com>
Date: 2004-06-30 16:02:47 CEST

Toby - thanks for your reply.

> So what happens three months from now when you need to do this again?
> Simply do an "svn update" from the root of your working copy,
> which will
> again send only file differences from the server to you -- not the
> entire repository. Then run your tool again, do "svn commit",
> and once
> again only deltas are sent across the wire.
> Unless your repository is extremely huge (say multiple GB),
> this should
> work without too much problem. If bringing down the entire
> repository is
> simply not possible, here's how I would do it:

I've got to admit, this approach (keeping the entire repository more-or-less
permanently checked-out) never occured to me. As far as disk usage goes, I
doubt it would be an issue since until very recently we were not using any
VCS at all, and were therefore already using about the same amount of disk
for code storage. (Well, half - I keep forgetting .svn contains an entire
copy of the checked-out files.) However, I do have other concerns regarding
this approach, several of which I suspect would cause my managers to have

> 1. Do an "svn list --recursive" of /trunk to get a list of
> every file in
> the repository
> 2. grep this list for interesting files
> 3. checkout only those files
> 4. run your update tool
> 5. do an update.
> This should be a very simple shell script or batch file; in
> fact, if the
> name of the config files is easily generated in a loop of some sort
> (i.e. it always looks like /trunk/<client>/config/foo.conf),
> you could
> even skip steps 1 and 2.

This intrigues me, specifically #3, since my previous experiences lead me to
believe this step cannot be done (at least without non-trivial coding using
the bindings). Also, did you perhaps mean #5 to say "do a commit" rather
than "do an update"?

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 30 16:15:39 2004

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

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