Är det någon här som är vass på Visual Source Safe och hur man arbetar med olika versioner av sina projekt i Visual Studio?

Exempel:
Jag arbetar just nu med ett ramverk som består av flera moduler. Varje modul är ett projekt i en solution. Allting är incheckat i VSS.
Just nu så är version 2.0 färdig och allt fungerar som det ska. Nu ska jag börja göra lite ändringar till 2.1 samt börja med version 3.0.
Då har jag nätplatser som fungerar med version 2.0. Dessa måste gå att göra ändringar i och uppgradera till 2.1, 2.2 osv. samtidigt som jag arbetar med 3.0.
Hur gör man?
Jag har försökt läsa mig till detta i VSS-hjälpen och på MSDN och har förstått att man användar Labels, Pin och Branch men jag tycker att exemplen är lite luddiga.
Jag har även förstått att det är lite lurigt att göra detta i VS och VSS av någon anledning.

Har ni någon bra sajt eller bok som visar detta på ett bra sätt?

Tar även gärna emot tips på andra lösningar. Har t.ex. hört något om att det finns ett VS.NET add-in för Subversion. Eller kanske någon lösning med CVS?

Någon som jobbat med någon source-kontroll lösning alls i VS.NET?

Jag har använt Source Safe mot VS.NET och det fungerar utmärkt - mycket bättre än i VB6.

När man färdigställt en version ska man sätta en Label på den. Detta görs lämpligen genom att man sätter en Label på mappen/projektet som programfilerna ligger i. Fortsätter man sedan utveckla applikationen, men vid något tillfälle vill återgå till en viss version, kan man ifrån History:n för projektet välja att hämta filerna för en viss Label.

Sedan går det ju att göra Branch eller helt enkelt kopiera in filerna till en ny mapp om man vill jobba med flera versioner samtidigt.

Ja, jag tycker att det fungerar bra att arbeta med Source Safe och VS.NET, det är just det här med flera versioner som verkar struligt.

Jag har inga problem att sätta en Label och fortsätta arbeta med projektet. Men att då återgå till en tidigare version handlar ju om att göra en RollBack. Jag vill arbeta med flera versioner av samma projekt. Men om man gör en buggfix i version 2.1 så måste den fixen komma med i version 3.0 också.

Om version 2 är en stabil release så vill jag utveckla nya projekt mot den versionen. Så när jag öppnar ett nytt projekt så vill jag skapa en referens till version 2. Version 3 jobbar jag vidare på men det ska inte påverka.

Om man läser i hjälpen till VSS, och på MSDN, så har de några exempel på detta:
<info>
To share, pin, and branch a project

1. In the drive toward Version 2.0, develop and test your project (e.g., $/Application).
2. Label the project "Version 2.0."
3. Begin changing files in the project in the drive toward Version 3.0 of the project, which will introduce new features.
4. If you realize an interim Version 2.1 is needed for bug fixes, select the project.
5. On the Tools menu, click Show History to display the Project History Options dialog box.
6. Select the Include Labels box.
7. Click OK to display the History of Project dialog box.
8. Select the label version "Version 2.0."
9. Click Share to display the Share From dialog box.
10. Select the project you want to be the parent of the newly created project. This is usually the $/ project. Also be sure the Branch after Share box is not checked.
11. Click OK to display the Share dialog box.
12. Give the project a New Name (e.g., $/Application V 2.1).
13. If the project has subprojects, select Recursive.
14. Add comments in the Comment box as needed, then click OK.
15. Click Close to exit the History of Project dialog box.
16. Select the newly created project (for example, $/Application V 2.1). All files in this project should now be pinned.
17. Select only those files that need to be changed to address bug fixes, then branch the file(s). See Branch Shared Files for more information. Leave pinned any files that do not need to be changed.

You can later merge bug fix changes back into your Version 3.0 project.</info>

Allt det här sker ju i VSS, inte i Visual Studio och det jag inte förstår är hur det påverkar de fysiska filerna och var version 2.1 dll:en och version 3.0 dll:erna skulle hamna.

Som jag har förstått när jag sökt efter information så funkar det inte riktigt som det ska eftersom Source Safe är en så gammal version. Det har inte hänt nånting de senaste åren utan man får vänta till VSS 2005.

Jag måste hålla med dig Patrik om att det är för luddigt i VSS och själv har jag faktiskt slutat använda VSS för mina egna projekt. Eftersom det oftast i mitt fall går flera månader eller kanske ett halvår mellan tillfällena när jag måste göra en större ändring i VSS så hinner jag glömma bort hur det fungerade :-) Att göra en branch på källkoden i utforskaren är ju jätteenkelt (dvs göra en kopia på källkoden till en annan mapp), där kan man knappt göra fel, men varje gång jag ska göra det i VSS så blir jag tveksam på exakt hur man ska göra och livrädd är man ju för att göra fel. Så jag låter utforskaren göra jobbet åt mig. Saknar i o f s möjligheten att kunna rulla tillbaka enskilda filer men det får man väl ta...

Ser verkligen fram mot en ny version av VSS som förhoppningsvis blir lite lättare att använda. Det är säkert inte så svårt att administrera VSS om man gör det dagligen, men hur många gör det? De flesta utvecklar ju och sitter mest och checkar in och ut och det lär man ju sig snabbt...

Jag har tyvärr väldigt lite erfarenhet av denna procedur. Jag vet dock att ms gjort en fix av detta till service pack 6:
http://support.microsoft.com/default.aspx?scid=321139&sd=msdn

Att hämta en tidigare version behöver inte betyda att man gör en Rollback, utan man kan ifrån History-dialogen göra en Get, vilket innebär att man lämnar kvar de senare versionerna i SS. Jag tror sedan att Merge-funktionen i SS är ganska bra, men har aldrig praktiskt använt den.