I have had developers sharing a working copy. I have had a few problems
with file locking or having an update or commit abort and had to run
"svn cleanup" on it but it's been ok. I've mostly used it for one
developer mentoring another one. A massive problem that I had that
didn't have anything to do with source control is template files. Some
of our developers were using Dreamweaver Templates. Anytime a template
was changed they had to make sure everyone closed every file that used
that template so it could be updated.
I really think that doing it how you're describing (having all the
developers share a single working copy) really defeats the purpose of
using Subversion. In your situation, you lose the ability to see who
made what changes and when, and makes it nearly impossible to cleanly
revert to a different revision since your commits will include changes
from all developers sharing that working copy. Both of these feature are
critical to web applications, in my opinion. The checkout-modify-merge
scenario also fixed the template problem since the programmers could
code while the graphics guys made template changes and everything would
happily be merged the next time an update was performed.
I think, ideally, that each developer should have his own working copy.
If they can't develop on their local system (using the Cold Fusion
Development server) then they should at least have their own working
copy on the web server (maybe in a subdirectory off of www). They access
it through Tortoise or command-line and update and commit as described
in the book.
You need to have a "staging" area that is updated from the repository.
In my organization, I wrote a Cold Fusion page that has a big button for
the developer to press that updates the staging area to the HEAD
revision. In my case, the staging area is simply a working copy and
pressing the button just does an "svn update" in that directory.
The live application is another working copy and when a revision is
deemed "stable", the live area is updated by the administrator, again
using "svn update" in that directory.
Doing it this way has saved my butt a whole bunch of times when a
developer (or, more often, a content creator) edits something they
shouldn't or just makes a mistake. 9 times out of 10 it's caught at the
staging server. If it's not caught there, it's trivial to roll back the
live server to the last known working version and go poke the person who
let the mistake get through.
The developers that I work with didn't want to work this way until they
made a massive cooperative mistake and realized that there was no way to
restore the web server back to where it was without going to tape backup
(and a couple of hours seems like forever when you know it's your
fault). Now they like it since they are able to freely edit whatever
they want and merge their changes with everyone elses later. Seeing the
files scroll by during an update also tells them what everyone else has
been working on which has fostered better communication (I won't say
more communication, but more efficient). They call it the "code now,
merge later" scenario and they like it a lot.
I recognize that you will have to do some work to the server to get this
set up and you'll have to use svnserve if you don't want to install
apache. I guess you could use a repository on a network share but that
makes me nervous. I had svnserve running for a year until I had to use
ssl for an outside developer and it became easier to just install
apache.
Good luck,
Rick Johnson
________________________________
From: Pat Wenke [mailto:pwenke@uhlig.com]
Sent: Thursday, October 21, 2004 10:16 AM
To: users@subversion.tigris.org
Subject: Subversion, TortoiseSVN, and Windows
I am in the process of evaluating SCM software and wondered if someone
could help me out.
All of our developers code in CFML. The box that hosts our development
code is a Windows 2000 server that runs both CFMX 6.1 and IIS 5.
The IIS and CF roots both point to the same directory on the server,
C:\www.
Currently we use no SCM software, so all developers map a drive to
C:\www on this server, and hence have no "working copy" directories,
other than their mappings to C:\www itself.
I have configured VSS in the past, where your "working copy" for
development can be the actual directory that is under source control, so
I'm
having a bit of a hard time wrapping my head around the newer SCM
concepts presented by Subversion and TortoiseSVN.
I can create a repository and connect to it with absolutely no problems.
I can then use TortoiseSVN to connect to the repository and import all
of our code from C:\www. My questions are as follows:
Can our developers somehow "share" a working copy, so that none of us
actually have to keep a local working copy?
Once I commit a changed file to the repository, how do I get the updated
version back into C:\www so it can be tested?
This particular phrase from the book is what I do not understand:
Now the repository contains this tree of data. Note that the original
/tmp/project directory is unchanged; Subversion is unaware of it. (In
fact,
you can even delete that directory if you wish.) In order to start
manipulating repository data, you need to create a new "working copy" of
the
data, a sort of private workspace. Ask Subversion to "check out" a
working copy of the repository's trunk directory.
What this tells me is that after I import C:\www into the repository, I
don't need it anymore. I understand that, and I understand creating a
working
copy, perhaps on my local machine, so that I can check out files and
make changes, and that the changes get committed back to the repository.
What I
do not understand is to which directory should I point my IIS and CF
roots, since C:\www is no longer needed.
I have given all the docs a thorough read and have Googled my eyeballs
out looking for answers, to no avail.
I am certain it's just a configuration problem somewhere. Any help is
greatly appreciated.
Thanks in advance,
Pat Wenke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 21 17:06:25 2004