Pat,
I would recommend against a 'shared' working copy. The purpose of the
working copy is to insulate the production code from code mucking.
Everyone who's interested in staying up to date with the repository as
they are working simply run svn update in their working directory before
making changes. When they are done editing, they svn commit their
changes back to the repository (simplest case) and when the release
manager is satisfied with the state of the code - pushes the change to
production (ideally integration test, then QA, then prod - maybe code
nirvana, but prudent nonetheless).
Here's a snapshot of a workable situation:
* The subversion repository is shared and holds the master copy of the
codebase (by design) and may have a trunk (main line of development) and
branches (deltas).
* The www directory is shared to allow any 'developer' of sufficient
stature to deploy code to.
* The working copy (location where the code is 'svn co' checked out
to)is specific to each developer and allows concurrent changes to be
managed.
A developer will be able to make changes to his/her own copy of a file -
say, index.html:
svn update
edit index.html
save index.html
svn commit
possibly merge changes if more than one developer made changes to the
same file
check with release manager and push the code to the www directory
Hope this makes sense to you...
Later,
Will
Pat Wenke wrote:
> 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 16:51:06 2004