>> 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