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 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 Andrew Connell IM on MSN andrew@aconnell.com
I think they have done it before you. :( Best regards, Alexandru Savescu
-
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 Andrew Connell IM on MSN andrew@aconnell.com
take a look at SourceOffSite www.sourcegear.com. They have a product called SourceOffSite Collab. Which is a collaboration / bugtracking application with sourcesafe integrated.
-
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 Andrew Connell IM on MSN andrew@aconnell.com
AC wrote: 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. I believe this was an apparent flaw to Microsoft, hence with ASP.NET you are able to use
XCOPYto implement new COM servers transparently over the old ones. AC wrote: 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 This is a good idea, we do this. :) Nick Parker -
AC wrote: 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. I believe this was an apparent flaw to Microsoft, hence with ASP.NET you are able to use
XCOPYto implement new COM servers transparently over the old ones. AC wrote: 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 This is a good idea, we do this. :) Nick ParkerNick Parker wrote: This is a good idea, we do this. Can you explain exactly how it's implemented if you don't mind? Andrew Connell IM on MSN andrew@aconnell.com
-
Nick Parker wrote: This is a good idea, we do this. Can you explain exactly how it's implemented if you don't mind? Andrew Connell IM on MSN andrew@aconnell.com
Andrew Connell wrote: Can you explain exactly how it's implemented if you don't mind? Sure, we use VSS to control all of our project, it's goofy to be nice, but once you get the hang of it, VSS can do wonders. This is especially true when you accidentally delete the wrong file out of the system.:rolleyes: We have a testing server we call....drumroll...
TESTBOX. This is where all our files are stored, and is only used per say for development. We have two instances of SQL Server installed on this box, one being calledTESTBOXand one calledTESTBOX/STAGING.TESTBOX/STAGINGis used when we are in beta mode of one of our applications. The actual server that holds the files for the application thatTESTBOX/STAGINGruns is separate fromTESTBOXthe server itself. Did I make that clear, or does it resemble coffee? :) Both these servers are intranet use only, we are only doing testing whether it be for the developer, or a beta mode test with end users. Nick Parker -
Andrew Connell wrote: Can you explain exactly how it's implemented if you don't mind? Sure, we use VSS to control all of our project, it's goofy to be nice, but once you get the hang of it, VSS can do wonders. This is especially true when you accidentally delete the wrong file out of the system.:rolleyes: We have a testing server we call....drumroll...
TESTBOX. This is where all our files are stored, and is only used per say for development. We have two instances of SQL Server installed on this box, one being calledTESTBOXand one calledTESTBOX/STAGING.TESTBOX/STAGINGis used when we are in beta mode of one of our applications. The actual server that holds the files for the application thatTESTBOX/STAGINGruns is separate fromTESTBOXthe server itself. Did I make that clear, or does it resemble coffee? :) Both these servers are intranet use only, we are only doing testing whether it be for the developer, or a beta mode test with end users. Nick ParkerNope... I understand you perfectly. Specifically, I am trying to figure out a way to use VSS without having people develop on their own boxes. Right now everyone is developing on the dev server. It's an ok solution because we only have a handful of developers (and typically one or two assigned to a project). However, when we grow it could get more challenging... but most importantly, there's no versioning control or source control and THAT is what our main goal is in getting out of VSS. I have worked with it before, I just used it in a poor implementation (as described in this thread). So... you check a file out and work on it on the development server or your local workstations (i.e.: You don't check it out to your local workstation, do your work, and them check it back in and publish the web project)? -AC Andrew Connell IM on MSN andrew@aconnell.com
-
Nope... I understand you perfectly. Specifically, I am trying to figure out a way to use VSS without having people develop on their own boxes. Right now everyone is developing on the dev server. It's an ok solution because we only have a handful of developers (and typically one or two assigned to a project). However, when we grow it could get more challenging... but most importantly, there's no versioning control or source control and THAT is what our main goal is in getting out of VSS. I have worked with it before, I just used it in a poor implementation (as described in this thread). So... you check a file out and work on it on the development server or your local workstations (i.e.: You don't check it out to your local workstation, do your work, and them check it back in and publish the web project)? -AC Andrew Connell IM on MSN andrew@aconnell.com
Andrew Connell wrote: So... you check a file out and work on it on the development server or your local workstations (i.e.: You don't check it out to your local workstation, do your work, and them check it back in and publish the web project)? VSS does keep a local copy on your workstation, but it should be a direct copy from the source database. When I save all my files at the end of the day or whenever, you would check this back into the VSS database. We manually move over the files when we go into a beta mode for testing for end users. You won't be able to completely control what file your developer decides to open (local or VSS), so you won't be able to have total control. I would suggest trying to make it clear to all of your developers the importance of source control to avoid any erratas later. :) Nick Parker
-
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 Andrew Connell IM on MSN andrew@aconnell.com
Since this would cost you a (probably rather hefty) bunch of money, perhaps you should try e.g. CVS first?