subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Mikesell <>
Subject Re: File access control
Date Sun, 02 Oct 2011 00:28:21 GMT
On Sat, Oct 1, 2011 at 6:15 PM, Grant <> wrote:
> 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?

How you move things around isn't as important as knowing what you are
moving.   And it doesn't really matter where the working copies are or
how many you have.

> So I'll be OK if I commit changes to the dev repository and then
> update from dev to production instead of using rsync.

Yes, that would assure that you can update to a known rev or tag.  But
so would any other working copy and using rsync from there.  If it is
convenient to use svn as a transport, go ahead but it isn't necessary.

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

You don't necessarily need another machine for staging, just a
separate working copy.   You may want dev work to continue on a
different schedule than your testing and releases.

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

In a larger scenario, each developer would have his own working copy
and likely a test environment (perhaps but not necessarily on separate
machines).  If their changes aren't likely to conflict, they can
simply commit/update to pick up each others' work.   If the changes
may conflict or some of the work won't be released until later you
would use branches to isolate it.   And at some point the separate
test/staging becomes more important as you need to integrate and test
changes that were developed separately.

   Les Mikesell

View raw message