Please be sure to use Reply To All to keep discussion on the list
On 3/7/07, smakawhat <smakawhat@yahoo.com> wrote:
> I had a feeling this was going to be a problem, but okay no problem I can
> take it from here.
Keep in mind that your issue with developers making changes to the
development and production servers has absolutely nothing to do with
Subversion or any other version control tool you might use. As long as
they have access to those servers, they can make the changes that you
want to prevent them from making.
> Thanks for your insight.
>
> Andy Levy <andy.levy@gmail.com> wrote:
>
> On 3/7/07, smakawhat 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.
>
>
>
> ________________________________
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 7 22:05:41 2007