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

Re: proposed export option

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 27 Apr 2010 08:13:47 -0500

Paul Breen wrote:
> Thanks for your reply, Ryan.
>
> On Mon, 4/26/10, Ryan Schmidt <subversion-2010b_at_ryandesign.com> wrote:
>> Changed since when?
> Changed since the last deployment. The routine would send the file
> sizes of the files on the deployed computer to the repository server,
> and if the file sizes differed from the file sizes of the given revision
> (the current revision by default), the server would send the updated
> file to the deployed computer.
>
>> I think
>> you'll be better off using existing solutions to this
>> problem, such as rsync from a local svn export to your
>> remote deployment, or even simply making your remote
>> deployment a working copy and using svn update there.
> My client is aware of rsync utility, but would prefer to use svn. I'll
> have to correspond with her to find out why she doesn't want to use
> rsync. As far as making the remote deployment a working folder and
> using svn update, she doesn't want to have the clutter of the hidden
> .svn folders on the deployed computers.

This is as simple as using a working copy as a staging point, doing an update or
switch to a release tag there, then running rsync with the -C option to copy to
the production location(s). Rsync also knows enough to copy only the changed
parts of a large file with small changes, and it builds the new copy under a
different name, renaming only when complete, where an svn export will probably
break running programs that have those files open.

-- 
   Les Mikesell
    lesmikesell_at_gmail.com
Received on 2010-04-27 15:14:21 CEST

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.