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

RE: Re: Moving from VSS to SVN - with Web based Shared Working Copies

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: Fri, 22 Aug 2008 09:44:12 -0400

>From: Ryan Schmidt [mailto:subversion-2008c_at_ryandesign.com]
>Sent: Thursday, August 21, 2008 2:48 PM
>On Aug 21, 2008, at 05:03, <c.jones_at_rgu.ac.uk> <c.jones_at_rgu.ac.uk>
>> We are just at the beginning of trying to move from VSS to SVN.
>> We've got our shiny SVN server all set up and running, but now it's
>> the practical changes that are causing us the headache. We're trying
>> to figure out how to move from VSS to SVN from our existing setup.
>> Currently we develop web applications using a shared development
>> server, so in VSS files are 'checked out' to a developer, edited
>> directly on the DEV shared area, run there while developing and then
>> checked in. Other developers can obviously see that those files are
>> being changed so must avoid them.
>> 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
>> interconnections with other systems, etc., for each developer on a
>> standalone machine?
>> This must be an issue for anyone developing web based
>applications, so
>> how do people deal with it out there? Any pointers, sites
>> this or anything at all would be great!
>> Our problem at the moment is the whole change to SVN seems
>> insurmountable because of this, and it's difficult to see any
>> incremental steps that we could take to get there. Clearly we can't
>> take three months out of 'ordinary work', just to completely revamp
>> our entire development process and environment, so we need
>to somehow
>> manage this is smaller stages.

>We also didn't want to replicate the development server
>environment on each developer's workstation, especially since
>the server was Linux and the workstations were Windows. We
>settled on keeping each developers' working copies in their
>public_html folder in their home directory on the Linux
>server, which developers would access via Samba and manipulate
>using TortoiseSVN. There was a little bit of work to rewrite
>our projects so they could run from an arbitrary server-side
>directory, but after that this strategy worked nicely.

From my experience in Web development, regardless of platform, the
optimal solution is to have all the web hosting capabilities available
on each developer desktop. For Java, that's something like Apache
Tomcat, for .NET that's Visual Studio 2005+ (need IIS for VS2003). For
others, it's probably Apache with an appropriate plugin (PHP, Python,
Perl, etc.). Configuration points to development servers for things like
databases and web services. Everybody is happy and adequately isolated.

Frankly, I've never experienced the "everybody edits the same copy"
environment, and I never will because I will not work for an
organization that has such a poor understanding of software development


All developers are lazy as evidenced by the amount of time and effort
spent in making a computer do the work. 
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
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-22 15:44:47 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.