Everybody else has had a go at this, so i think I will too...
If you are using subversion, you can more or less keep your existing
process, in fact subversion makes some steps easier.
Assumption: you have a server set up somewhere with a subversion
repository on it and the current state of your code has been imported
into it.
On 21 Aug 2006, at 21:45, The Dan Keefer wrote:
> First, thanks go out to all the respondents.
>
> Yes, I am largely unfamiliar with source code management and
> version control software. I understand most of the issues, but I
> know that the powers to be aren't going to want (or be able) to
> completely change everything we do.
>
> Every developer has his own copy of CF, SQL Server, and code.
Nothing changes except that the developer originally obtains his copy
of the code by checking it out of the subversion repository. When
you check the code out, you can put it in *any* local folder you
like. Once checked out, the folder containing the code becomes a
working copy. There is no difference between a working copy and any
ordinary folder except it contains a hidden .svn directory which
subversion uses for house keeping, If you rename, move or copy files
about within the working copy, you should use the subversion commands
to do it rather than your OS commands (so subversion can update the
info in the hidden .svn directory).
>
> Typically when we are asked to either develop or or fix something,
> we do it on our local copy. Each of us copies our changed/new files
> onto a development server and copies the changed code of others
> onto our local copies. We are to check the time stamp of each file
> as it it copied.
Nothing changes except when your developers have completed the
changes they "copy" the files back to the repository using the svn
commit command. They only need to do this once in the top level of
the working copy and subversion handles all of the tedious time stamp
checking for you. It will commit all of the changed files and only
the changed files.
To "copy" the changed code of others into your local working copy you
just do an svn update command. Again all the tedious time stamp
stuff is done automatically by subversion. The svn update command
will get all of the changes committed by all of the developers.
>
> We are well aware of the problems with this process, which is why
> we are looking into Subversion.
>
> However, not only do our copies need to run independently of the
> server, but the server is used for testing development by non-
> programmers so it is considered the latest development copy, though
> there are works in progress.
This is where you need to make some changes. The subversion
repository is a database and you should think of it as an opaque
blob, All of the directory structure and files etc are maintained in
it but not in a form that humans or web servers or file system
syscalls can understand.
What you need to do is check out a working copy onto your test server
that your CF test system uses. In order to keep it up to date with
the changes committed by your developers, you need to run an svn
update on it regularly. You can do this in various ways:
1. have the test manager run an svn update whenever he wants to
bring the test server code base up to date
2. run a regular scheduled job to do the update e.g. once every day.
3. write a "post commit hook" script that runs svn update on the test
server working copy each time somebody commits changes to the
repository. Lot's of people have done this, there may even be an
example in the svn distribution.
>
> It SOUNDS like each time a file is changed, it goes into a new
> folder (potentially) so that the latest version isn't in the web
> site path anymore.
Your current problem is that you are using one set of code for both
the test system and your "repository". This should stop whether you
choose to use subversion or not.
>
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 22 11:36:09 2006