Implementing VSS in a web-based environment...
-
We're currently exploring our options in relation to source control, version control, and deployment. We are primarily web development, but are getting into some application development as well. I've used VSS before in a web environment and I was not impressed (this can be strictly because of the way it was implemented, so take it for what it's worth). Basically, we had a VSS database on our shared development server. Then, we would each do development on our own workstation. When we checked a file in, it would be in the VSS database. Next time someone went to work on the project, they would download all the changed files to their workstation. There were some major flaws in this process in my mind: each workstation HAD to be configured identically in terms of directory structure, IIS settings, web process within IIS, etc. One of the BIGGEST problems I saw was that each user had to create a web process in their own local IIS AND everytime a new COM object was built/changed, we would have to ensure all developers unregistered the old object and registered the new one. Granted, this can all be accomplished with some batch files or scrpts, but that just seems like it shouldn't be necessary. Ideally, I'd like to have a single web process on a development server that we can develop against, but have some sort of source & version control & collaboration built in. There must be a better way... and I'm sure someone has done it. The trick is we want the same VSS solution to work for desktop app/client-server development (not the one development server... but just use a single source control). Your input would be greatly appreciated. -AC Andrew Connell IM on MSN andrew@aconnell.com
-
We're currently exploring our options in relation to source control, version control, and deployment. We are primarily web development, but are getting into some application development as well. I've used VSS before in a web environment and I was not impressed (this can be strictly because of the way it was implemented, so take it for what it's worth). Basically, we had a VSS database on our shared development server. Then, we would each do development on our own workstation. When we checked a file in, it would be in the VSS database. Next time someone went to work on the project, they would download all the changed files to their workstation. There were some major flaws in this process in my mind: each workstation HAD to be configured identically in terms of directory structure, IIS settings, web process within IIS, etc. One of the BIGGEST problems I saw was that each user had to create a web process in their own local IIS AND everytime a new COM object was built/changed, we would have to ensure all developers unregistered the old object and registered the new one. Granted, this can all be accomplished with some batch files or scrpts, but that just seems like it shouldn't be necessary. Ideally, I'd like to have a single web process on a development server that we can develop against, but have some sort of source & version control & collaboration built in. There must be a better way... and I'm sure someone has done it. The trick is we want the same VSS solution to work for desktop app/client-server development (not the one development server... but just use a single source control). Your input would be greatly appreciated. -AC Andrew Connell IM on MSN andrew@aconnell.com