On 3/7/07, smakawhat <smakawhat@yahoo.com> wrote:
> Hi all, I have spent time playing around with subversion and I think it's a
> pretty neat looking tool. I am thinking of getting this into use for our
> development and production website environments which run on IIS using
> classic ASP for now and eventually .NET. I am also using Tortoise to do the
> checkouts/commits create a repository, make working copies so far. Keep in
> mind I am doing this all with Tortoise as well.
>
> Well I understand this idea of checking out stuff and what the purpose of
> this tool is for. What I am stuck on is how to deploy this and set it up
> properly in our existing environment so that the developers can't
> "circumvent" subversions purpose.
>
> I'll explain what I am getting stuck on. This is our current setup which I
> am sure you all have seen. We have development server "D", containing
> classic ASP pages. We modify these and copy over the changes to production
> server "P". We have only 2 developers doing this who have access by network
> shares.
>
> What I am getting stuck on is once I import the contents of the development
> into a repository (I made it on the D server), and the two developers can
> commit and make changes and all that stuff to their local working copies..
> I notice there is nothing from stopping either developer from working on the
> D server to alter the original files that are in the repository. Also when
> the developer has commited his changes to the repository, how do I get these
> onto the server from subversion??
Nope, Subversion won't stop developers from modifying the files on D
or P, because that's not its job. Cut off their access to that network
share.
You need to allow, via permissions & process, only one method to get
files onto D and P. Typically what one will do is either install a
post-commit hook script to do the deployment, have a person in a
release manager role who does the deployment, or use other tools to
make it happen.
The workflow SHOULD be:
Developer checks out their WC
Development
Local unit testing
Developer commits changes
Release updates to dev server
Test
Approve changes
Release updates to production server
> This of course would also happen for the P server as well, cause both
> developers have local shares to the P and D servers to copy over the ASP
> pages regardless of what is in the repository. So what am I missing for
> deployment here? I thought about making the actual web site on development
> a working copy but that obviously makes no sense...
Actually, putting a working copy on the dev server makes a lot of
sense. It makes it a lot easier to update the code on the server - you
don't have to cherry-pick individual files, and it's much faster and
more efficient than pulling the whole project every time.
> I do have things set up as fsfs for the repository cause of the network
> share access.
>
> Forgive what is probably an obvious thing I am missing, but I have been
> playing with this thing for days. I can make the repository, set up working
> copies, but I can't figure out how to prevent people from altering the
> development (and eventually the production) web files on the server without
> going through subversion first.
>
> What am I missing? My brain is just not hacking this right now.
What you're missing is that you've still given the developers access
to D and P via file shares and maybe even a local logon. You have to
sever that access. They'll probably scream and complain, but it's the
right thing to do if you want any solid version control and release
management. This is a key component of building a mature software
development process.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 7 21:00:41 2007