rsync with copy-dest

[Eric Kolve]

I have uploaded a tar of a copy strategy 'rsync' into this group
'rsync_copy_dest.tar'. It uses the --copy-dest flag provided by rsync
to reference the most recently deployed release as the local copy to
compare against.

--copy-dest=DIR
This option behaves like --compare-dest, but rsync will
also copy unchanged files found in DIR
to the destination directory using a local copy. This
is useful for doing transfers to a new
destination while leaving existing files intact, and
then doing a flash-cutover when all files
have been successfully transferred.

Multiple --copy-dest directories may be provided, which
will cause rsync to search the list in
the order specified for an unchanged file. If a match
is not found, a basis file from one of
the DIRs will be selected to try to speed up the
transfer.

If DIR is a relative path, it is relative to the
destination directory. See also --com-
pare-dest and --link-dest.

The nice thing about this is that a new release will get all the code
previously released plus any changes made, making the copy extremely
fast.

The steps for the strategy are:

1) checkout revision from SCM to local directory
2) rsync data out to all servers with --copy-dest and checksum flags

The only downside i see to this is that it depends on a rsync
executable. If there is interest in incorporating this into the
project, i could probably create something in pure ruby that would be
rsync-like and accomplish the same thing.

--eric

[Izidor Jerebic]

On 16.10.2007, at 18:31, Eric Kolve wrote:

>
> I have uploaded a tar of a copy strategy 'rsync' into this group
>

Well, it seems that we'll wind up with many many rsync deployment
strategies. At least four and still counting. Just search the
archives...

> The only downside i see to this is that it depends on a rsync
> executable. If there is interest in incorporating this into the
> project, i could probably create something in pure ruby that would be
> rsync-like and accomplish the same thing.

I don't think this is a good idea. Actually, I think it is a very bad
idea...

There are certain features of rsync that are rather hard to
implement, e.g. rsync can transfer only the changed parts of files,
which comes handy when time stamps are different (but file contents
are the same) due to way the scm exports files. Not to mention
correct handling of file attributes and weird file types, pipelining
of processing and networking, robustness etc...

Rsync is a quite clever and well-tested program for transferring files.

izidor