Visual Source Safe...
-
what i am seeking is some guidelines. Picture this: I have a team developing the same application , and we use VSS. We do not release major Versions, we distribute our application by releasing small builds, and every time i send one build to the testing people, i will wait for their feed back while my team starts new features (for the next build). Now, if i place a "label" in VSS marking the "beta build" and my team starts woking again, the label will not do me any good because its does not reflect the build that will be sent to the customers. On the other hand if wait until i have the build ready to send to the customers, i can not place a label on VSS because the code will have changes made by my team after i send the build to testing people. For this to work this way i would have to give "vacations" to my team whil in testing fase. :-D Not very good ... :doh: How do i solve this? How do you test a build and work on the next without multiple copies of the source code?
-
what i am seeking is some guidelines. Picture this: I have a team developing the same application , and we use VSS. We do not release major Versions, we distribute our application by releasing small builds, and every time i send one build to the testing people, i will wait for their feed back while my team starts new features (for the next build). Now, if i place a "label" in VSS marking the "beta build" and my team starts woking again, the label will not do me any good because its does not reflect the build that will be sent to the customers. On the other hand if wait until i have the build ready to send to the customers, i can not place a label on VSS because the code will have changes made by my team after i send the build to testing people. For this to work this way i would have to give "vacations" to my team whil in testing fase. :-D Not very good ... :doh: How do i solve this? How do you test a build and work on the next without multiple copies of the source code?
I put in a #define VERSION_NUMBER "put something here" in my stdafx.h file. Then I use VERSION_NUMBER in my about box, or anywhere else I need to use it. But maybe in your case it would be best to just check the project out each time and check it in with a comment My articles www.stillwaterexpress.com BlackDice
-
I put in a #define VERSION_NUMBER "put something here" in my stdafx.h file. Then I use VERSION_NUMBER in my about box, or anywhere else I need to use it. But maybe in your case it would be best to just check the project out each time and check it in with a comment My articles www.stillwaterexpress.com BlackDice
Yes , but the problem is how to control the changes that are made after the build get sent to testing. IE: I send a build do testing and wait for feedback. While i am waiting, i what my team to keep working, but if they change the resources (for example), i will have no way to solve any bug in the build that was sent to the testing whitout the changes that have been made geting in to.
-
what i am seeking is some guidelines. Picture this: I have a team developing the same application , and we use VSS. We do not release major Versions, we distribute our application by releasing small builds, and every time i send one build to the testing people, i will wait for their feed back while my team starts new features (for the next build). Now, if i place a "label" in VSS marking the "beta build" and my team starts woking again, the label will not do me any good because its does not reflect the build that will be sent to the customers. On the other hand if wait until i have the build ready to send to the customers, i can not place a label on VSS because the code will have changes made by my team after i send the build to testing people. For this to work this way i would have to give "vacations" to my team whil in testing fase. :-D Not very good ... :doh: How do i solve this? How do you test a build and work on the next without multiple copies of the source code?
Has anyone suggested Branching? Basically, we have the "main branch" which contains all new development. When I want to put a version into testing phase, I create a branch in a "Releases" folder and call that branch "Version A". I continue working on the main branch. Then, in testing, version A has a problem. I can create a new project off of Version A, and make the changes only to version A. Then recompile, continue testing. Once you confirm that you want those changes from version A in your main branch, you merge in the changes from Branch A into the Main version. Now main version has the fix you found, and your new development, but Version A is at a stable stage that it can be deployed. PS I know you guys wrote back in May, but I was searching around for info on Source Safe Command Line stuff. Cheers.