>> My workflow above only describes a single repository on the dev
>> machine, the production machine wouldn't have a repository. rsync
>> would synchronize the source files, not the repository.
>>
>
> Normally you would do that with a subversion client, creating
> different workspaces for development, testing, and production with
> commit/update operations to move data instead of rsync. Variations
After committing changes to the repository on the dev machine, could I
use svn update instead of rsync to bring the production machine's
files in sync with those on the dev machine?
> on that are possible, but you really don't want to set up a path that
> has a way to get something into production that wasn't committed as a
> known revision or tag. Rsyncing from a test/staging copy to
> production is probably ok - going straight from the development
> workspace where changes are being made would be more risky.
Is it risky because I would be using rsync instead of svn update, or
is it risky because I wouldn't be using a test/staging machine? Why
can't testing be done on the dev machine?
- Grant
Received on 2011-10-01 08:17:33 CEST