Je zou een van de examples kunnen proberen. Je krijgt dan een idee wat de API kan en hoe je de API kunt gebruiken om te bouwen wat jij wilt.
Echter, sourcecontrol is voornamelijk organiseren: afspraken maken en die executeren dmv het gebruik van een sourcecontrol systeem. VSS is net als andere sourcecontrol systemen niets anders dan een beheerder van een centrale database waar meerdere versies van files binnen projects zijn opgeslagen.
De tool die je gebruikt om filedata in die database te updaten/raadplegen/beheren is de VSS Explorer. Daarmee kun je conflicten oplossen, nieuwe projects aanmaken etc. Maar, feitelijk gebruik je die tool zelden, want in de MS tools zit deze tool geintegreerd: als je een nieuw project aanmaakt in bv VC++, kun je dat project automatisch toevoegen aan VSS.
Even je punten langslopen wat je wilt.
1. Een eenvoudige manier (tool/script of werkinstructie) voor het aanmaken en vullen van projectstructuren in Microsoft Visual Sourse Safe.
Dit is een van die organisatorische zaken waar ik over sprak: wie maakt de projecten aan? Wie shared binnen de VSS database(s) de bestaande code in projects? Wie beheert de projects zodat alleen de juiste developers toegang hebben tot de juiste code? HOE beginnen developers een project? wordt dat voor ze aangemaakt of beginnen ze zelf een project en voegen ze dat later zelf toe aan een VSS database? (essentieel verschil)
Je kunt vanuit de MS devtools de projects automatisch aanmaken. Als je bv een wizard maakt voor VC++, dan kun je daar code aan toevoegen die behalve je projectstructuur genereert, hem ook toevoegt aan VSS. Vaak wil je echter dit anders doen: de kracht van sourcecontrol databases is het sharen van code over meerdere projecten, zodat wanneer je de code update, alle projecten die die code gebruiken, worden geupdate.
Dit kun je dus oplossen door een werkinstructie te maken voor de projectbeheerder die in VSS de projecten aanmaakt, daarin de juiste sourcecode shared vanuit andere, al bestaande projecten en de users toewijst aan dat project. Developers openen dan de VSS explorer en checken de code uit, bewerken het en gaan er mee aan de slag.
2. Backup procedure
VSS is filebased, backup gewoon de data dir van elke vss database met je backup tool (NTBackup of een andere tool).
3. Versie beheer procedure (procedure en werkinstructies)
Dit is ook weer een organisatorisch probleem en is op te lossen middels afspraken binnen de organisatie: wie bepaalt wanneer een codebase een 'milestone' heeft bereikt? Wie gaat dat dan ook doorvoeren in de VSS database? (labeling). Kijk ook naar de geavanceerde feature in VSS mbt updating van gebranchete trees: als je project A hebt in versie 1.0 en je wilt versie 2.0 ontwikkelen op basis van versie 1.0 maar versie 1.0 ook verder onderhouden (bugfixes), dan branche je de tree, en bugfixes doe je in de 1.0 tree, verdere ontwikkelingen doe je in de 2.0 tree. Wanneer je een bugfix hebt gedaan op v1.0, dan kun je die mergen met de 2.0 tree zonder dat je code van v2.0 aantast (bij conflicten kun je kiezen welke wijzigingen je wilt overnemen). Dit moet je oplossen middels afspraken in je organisatie wie dit mag doen en wanneer. De tool helpt je dan bij het uitvoeren ervan, maar onthoudt: wie de knoppen bedient is niet te bepalen door de tool, maar door afspraken en dus werkinstructies.
4. Source vergelijk procedure (op file nivo)
Dit kom je zelden tegen, maar als je het wilt, dan kun je in VSS Explorer de historie induiken van een file (bv 10 versies terug gaan, en die vergelijken met een file op disk (bv de uitgecheckte laatste versie). Visueel, dus erg makkelijk.
5. Source vergelijk procedure (op project nivo)
Dit kom je NOG minder tegen, maar windiff is je vriend. ('get' een label in een andere dir dan de huidige versie, haal alle files door windiff)
Ik krijg het vermoeden dat het concept sourcecontrol nog niet helemaal duidelijk is. Wil je een echt goed antwoord voor jouw situatie dan is het denk ik nodig dat je uitlegt waarom je VSS wilt gebruiken en hoe je projectteam is georganiseerd: VSS is bedoeld voor conflictbeheersing bij parallelle ontwikkeling aan 1 project: zodat meerdere mensen niet dezelfde file editen en dat je versioning hebt mbt waar je aan werkt. T.a.t. werkt men echter met een 'snapshot', een versie uit de vss database. DAAR werk je mee als project.
:strip_exif()/u/26181/Hunnypot-new60.gif?f=community)
:strip_icc():strip_exif()/u/809/LegoSpaceMan_Icon_XS.jpg?f=community){kind=icon}
/u/13464/Delphi.png?f=community)