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

Re: File access control

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Fri, 30 Sep 2011 22:25:15 -0500

On Fri, Sep 30, 2011 at 9:16 PM, Grant <emailgrant_at_gmail.com> wrote:
>> 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?

Yes, and even better if you have an intermediate staging/testing
space, but that may be overkill for some situations.

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

One of the things you get from version control is the ability to roll
back to any version that was ever committed. If you move things
directly from the development workspace to production, you have the
opportunity to copy something in that has not been committed to the
repository. Now, if you make additional changes, and the next
version has a problem, you won't be able to roll back or even see the
differences from the now overwritten version that worked previously.
You could use other procedures to make sure that the version that is
put in production exactly matches a committed revision, but the easy
way is to use a workflow where the only way to move files is to commit
from the place where the changes are made, and update in a different
workspace. Also if you ever have more than one developer doing
changes at the same time, you may want that separate testing workspace
where you make sure that all the parts still work together.

-- 
   Les Mikesell
     lesmikesell_at_gmail.com
Received on 2011-10-01 08:12:32 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.