>> 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.
Would I need to install subversion on the production machine, or would
the subversion server running on the dev machine just treat the
production machine as a target destination and use SSH to transfer the
files?
>>> 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.
So I'll be OK if I commit changes to the dev repository and then
update from dev to production instead of using rsync.
I'm trying to get the dev/staging/production thing clear in my mind.
The way I imagine this working is I install a copy of my production
machine onto a dev machine and a developer works on some of the code
on that dev machine and is able to test his changes on that machine as
he goes. Once everything is done and verified, his changes are
exported to the production machine. Where does the staging machine
come in? Why is it needed in addition to the dev machine?
I can see how multiple developers would really complicate things. Now
that I think about it, wouldn't development on the dev machine be
impossible if two developers are working on separate things that
happen to interact with each other? They wouldn't be able to test
their changes properly as they're coding. How is that handled? A
separate dev machine for each developer?
I think I'm missing something here. Could someone straighten me out?
- Grant
Received on 2011-10-02 01:16:18 CEST