Hi Shawn,
We had a similar problem, and at a certain point, our "FOO1.0" project could no longer be maintained under source control. Our solution was a combination of 2 and 3. We shared the entire project to "FOO1.6", and branched individual files as necessary. For shared files, this allows you to implement a fix once that will apply to both projects. You can branch files that contain new "FOO1.6" features. I have some notes on our specific implementation that I can email you, if you're interested. The VSS docs aren't very good. There is also a book available at
www.hentzenwerke.com.
>I'm having a problem trying to understand the best way to implement versioning with options such as LABELS, BRANCHing, SHAREing and PINing. I'd like to layout my intent and get peoples opinions on the best way to implement.
>
>Product FOO is starting from scratch. Its a VFP project with forms and programs and with nested directory structure. At the beginning all of the files are added to a VSS project under the root called FOO
> $/FOO/
>
>Development is done on Version1.0
>The build and testing are successful and we're ready to start working on version 1.6 which will be our second quarter release.
>
>At this point should I
>
> - LABEL the entrie project "V1.0" and then use that to maintain
> version
> - BRANCH a new project under the root $/FOOv1.0
> - SHARE (not really even sure how that implements)
>
>I tried the LABEL method and here's what I found
>
> - continued development on v1.6
> - Found a bug in core code of v1.0 that must ship immediately
> - Do NOT want to introduce other problems by including the
>current source
> - Navigated VSS history and downloaded all files for "V1.0"
> - Modified v1.0 problem file and recompiled.
> - Succesfully got my "patched" v1.0 program
>
>Now this is the point I hit some issues.
>
> - Check-in the modified v1.0 file
> - Label that file "V1.0" so that it applies to that "Label section" of the VSS DB
> - Do get latest version
> - The modified file from v1.0 that was checked in and re-labeled "V1.0" comes down with the latest version (expected latest version of file after those labeled "V1.0")
>
>I was able to fix as
>
> - Use VSS history to find the v1.6 file version in the list
> - GET that version of the file down to the v1.6 working directory locally
> - Check out file of VSS (did not get local copy though... already have from above)
> - Check in file again to make it the latest version
> - Now a GET LATEST version works as expected.
>
>
>The problem is this seems like a methodology that will invite errors (regarding using the labels...check-in...etc from above). So I'm thinking if I understood the BRANCHing and SHAREing better I might have my answer.
>
>So I'll be working away "Brute-Force" style trying to get the answers, but I appreciate any insights from those who have been victorious with their sourceSafe battles.
