> -----Original Message-----
> From: The Dan Keefer [mailto:dan_keefer@yahoo.com]
> Sent: Monday, August 21, 2006 2:14 PM
> To: users@subversion.tigris.org
> Subject: Running Code
>
>
> Folks,
> Recently we attended the Coldfusion conference in
> DC and one of the presenters talked about using
> Subversion for version control.
>
> I downloaded the "book" and read the first few
> chapters and got a basic idea of how it works. Very
> basic.
It sounds as if you're not very familiar with version control,
change management, processes, and CM (configuration management) in
general. You need more than just subversion.
>
> However, I have a couple concerns and don't know if
> they are legitimate or not.
>
> Our environment is such that 4-5 developers write
> code on local machines and we copy our new files and
> changes to a server for others to copy to their machines.
The 4-5 developers check in code. The code now resides on the
server. The other developers run 'svn update' or 'svn co' to get to the
other people's code. The QA weenies can run 'svn co' or 'svn export' to
deploy the code from Subversion to their testing servers.
>
> The code is in one folder with perhaps three subfolders.
>
> 1. It sounds like Subversion would require you to copy
> the entire code each day if you wish to remain current.
Use 'svn update'. It will update your workspace with code
that's been checked into the server. It's a delta pull, not a full
checkout from scratch.
>
> 2. Nothing I saw in the documentation seemed to clear talk
> about running the code as you test things, which obviously
> requires access to more files than those you have changed
> or added as well as an expected path.
Your code is checked out to a workspace which acts like a normal
file system except that you need to ignore the .svn directories. You
should be able to run your code from a workspace as you're working on
it.
>
> How do you rectify all these version with having to test
> the code as you are debugging it.
That's a process problem. Right now you have people
independently deploying to the server and independently testing their
independently developed changes. (You may substitute 'independently'
with 'randomly' in the precious sentence.) How do you rectify (and
manage) the situation now?
You can use workspaces, branches, formal code drops (by tag or
revision), etc. to manage what gets deployed and tested. You'll
probably also want to get a change management system to tie into
subversion.
Subversion will handle the version control side, but you really
need to look at your overall process for delivering and managing code
changes.
>
> Right now we simply call our software using HTTP and a
> known path.
Actually, your http and path points to a bunch of files
somewhere. You can create that bunch of file using 'svn co' or 'svn
export'.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 21 20:55:45 2006