I would suggest that, rather than have your development machine do
frequent updates, give each developer separate folders on your
development server that is their space and they will map a drive to it
as now. Map a virtual directory to each developers folder in IIS that
can be accessed via web server (http://developmentserver/developer).
Developers check out whatever projects they work on into folders on that
drive. Developers code and test and periodically hit Update in Tortoise
(or 'svn update'). When appropriate, they commit code to the repository.
I think that in the above situation, code can go from their working copy
(tested against the other code in the repository) straight to the
staging server.
If you feel you need a communal testing area on the development server
then use either a hook script (if the repository is hosted on the
development server) to update whenever a commit occurs or use
CruiseControl or Draco.Net.
Since, in your situation, developers manually update the staging server,
I would continue with that only they would either do it through an SVN
client (Tortoise or 'svn update drive:\path\to\staging\area') or through
a web page as I described earlier.
Project manager decides what revision is to be made live and updates the
live server to that revision.
I think that in your scenario below your concern about your developers
keeping their local working copies updated is well placed. If that isn't
what they're always working from then it becomes difficult to maintain
it even if they wanted too. I realize that the idea of setting up
separate areas for each developer and setting up virtual directories in
IIS seems intimidating but it's not that bad and doesn't change very
often anyway. The last time I had to do it, it took me about an hour to
do 25 developers.
Rick
-----Original Message-----
From: Pat Wenke [mailto:pwenke@uhlig.com]
Sent: Thursday, October 21, 2004 1:04 PM
To: users@subversion.tigris.org
Subject: Re: Subversion, TortoiseSVN, and Windows
I appreciate all the replies. This discussion has given me some major
insight into SCM and setting up development environments. Perhaps I
should also explain our current development environment in further
detail.
Our developers write code on their drives that are mapped to the C:\www
folder of the development machine. Development websites that reside on
this development machine are how and where the development code is
tested.
Once the development code is tested, it gets merged to C:\www of our
staging server, to which the developers also have mapped drives.
Staging websites that reside on this staging machine are how and where
the staging code is tested.
Once the staging code is tested, our project manager merges the code
into production.
Here is my current understanding of how we would use subversion:
Aside from having each developer run IIS and CF locally, which we don't
currently do (and are trying to avoid), our development machine will
have to do rather frequent updates of its own working copy, from the
repository, possibly using a tool like cruisecontrol. Each developer
will also have a working copy on their local machine that they
periodically commit to the repository.
It is not likely that we will do any branching.
Do I need to be concerned about everyone keeping their own working
copies consistently up to date?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 21 19:43:10 2004