Campbell, Matthew A wrote:
>Obviously, these changes need to be updated into our repository once
>completed. The "obvious" approach will almost certainly work - that being
>"svn co http://server/svn/trunk", run the modification program, then "svn
>commit" from the "trunk" working copy. However, this approach is nasty,
>time-consuming, and something of a bandwidth hog in our situation - not to
>mention that I'm concerned about this activity spike more-or-less
>incapacitating the Apache server for the duration of the checkout.
>
The only "nasty" part about this approach might be the very first time
you checkout the working copy. After you run the mod tool and do "svn
commit", only file differences will be sent back across the network. By
keeping a pristine copy of the original in the .svn directory, the svn
client is able to determine file changes without asking the server. A
simple way to put it is that it sacrifices local disk space for the sake
of network bandwidth.
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:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 30 00:24:39 2004