c.jones_at_rgu.ac.uk wrote:
> If we move to SVN in this scenario, we have the obvious problem that you can't really have more than one person changing the shared working copy at once - it defeats the whole copy-modify-merge thing.
>
> The obvious thing is to develop on a local working copy, however this has it's own headache - how on earth do you replicate a huge development server, the databases, application server configurations, interconnections with other systems, etc., for each developer on a standalone machine?
>
Well, we migrated from VSS to SVN a good while back and we in fact do
replicate the full environment for each developer's machine. You already
wrote yourself that your currently intended approach would defeat SVN's
copy/modify/merge paradigm, so i suggest to go down the (initially)
rocky road of replicating the setup on each developer's machine. This
way, your developers are also much more involved in how all your
components interact with each other and i bet that many of them will
give you valuable feedback about your current system architecture.
To tell the truth, however, we had a similar approach back then with
VSS, so our mileage varied a lot from yours, though. (Of course we had
some issues, but those were not in the developer machine setup but
rather that we were unable to migrate the old VSS history to SVN, so we
ended up with a fresh SVN repository and the old VSS database still
online in read-only mode. You apparently have no trouble in this area,
so consider yourself lucky!)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-21 12:22:25 CEST