[IDE] Visual Sourcesafe & Visual Interdev

[Mart!]

Ik hoop dat de volgende lap tekst jullie niet ontmoedigd om me te helpen aan een oplossing:

Ik heb vandaag bijna een halve dag op m'n wer besteed aan het installeren van Visual Sourcesafe en Visual Interdev, op zo'n manier dat het allemaal samen zou moeten werken. Hiervoor heb ik de volgende zaken gedaan:

Op de IIS Server geinstalleerd:
- Frontpage Extentions 2002 (Ja, die zijn nodig...)
- Visual Sourcesafe database en server files

Op de client geinstalleerd:
- XP met IIS
- Visual sourcesafe client files
- Visual Interdev

Ik ben zover gekomen dat ik een project (of eigenlijk solution) lokaal op mijn webserver draai en deze kan syncen met de master versie op de server. Nu wilde ik echter op de IIS server sourcesafe gebruiken, zodat (volgens MS) de volgende situatie ontstaat:



Zie ook: http://msdn.microsoft.com...ml/viconsourcecontrol.asp

Helaas blijf ik op het einde steken. Ik kan nu files van de master server halen om lokaal te bewerken, waarna ik deze weer terug kan zetten op de master server. Dit kan allemaal via Visual Interdev. Wat echter niet gebeurt, is dat deze automagisch in Sourcesafe worden uitgecheckt en ingecheckt. Het gaat fout bij het aanmaken van een project in sourcesafe via Interdev.

De vraag is of iemand hier ervaring heeft met deze setup en wellicht weet wat ik fout doe. Ik heb al geprobeerd om de IUSR_Machinename toe te voegen aan de Visual Sourcesafe users, zoals MS dat aangeeft, maar ik krijg het niet voor elkaar om het project in VSS aan te maken.

[Mart!]

Het is vnmorgen gelukt! Wat ik heb veranderd:
- Ik heb in de Frontpage server extensions een role angemaakt die source control mag doen
- De anonymous user (dat is dus IUSR_Machinename) heb ik die role toebedeeld.
- Ik heb in Interdev aangegeven dat ik onder souce control wil werken

Vervolgens worden alle files netjes in Visual Sourcesafe gezet en krijg ik netjes de opties Check out/Check in bij de files in m'n project...


Update
Het werkt dus nog niet helemaal ok. Het project wordt nu in source safe opgeslagen maar bij het uitchecken gaat het is. Ik krijg dan de volgende foutmelding:

Unable to check out file '<file>'. Server error: Visual Source Safe failure. A "You currently have file <pad>/<file> checked out" error has occurred while operating on file "<pad>/<file>" Verify that the file's permissions are correct and that you have write access to the Visual Source Safe repository.

Dit heb ik dus gechecked en het lijkt allemaal wel ok. Ik heb een gebruiker aangemaakt voor de source safe database die ik gebruik, maar op een of andere manier kan ik een file alleen maar uitchecken. Ik zie dan niet dat de file is uitgecheckt (in interdev) en ik kan hem dan ook niet inchecken. Uitchecken kan wel (nog een keer) mr dan krijg ik dus bovenstaande foutmelding.
Ik ben nu de weg dus helemaal kwijt. Iemand een idee?

[ Voor 52% gewijzigd door Mart! op 24-12-2002 09:53 . Reden: omdat het nog niet werkt ]

[EfBe]

Als ik je een raad mag geven, doe dan het volgende. Dit is de werkwijze zoals wij die hanteren en werkt op zich het beste, omdat je dan beter functionaliteit van sourcesafe benut, bv sharing en branching van files.

- frontpage server extensies uninstallen. Die heb je niet meer nodig. Alle _vti_* directories verwijderen.
- Iedere developer krijgt de sourcesafe client.
- Je checkt nu de complete sites in in sourcesafe via de sourcesafe client (die explorer). Zonder de interdev project files, die heb je niet meer nodig.
- Iedere developer zet bij het project in de sourcesafe client als working folder de folder op de webserver. (iedere developer heeft op zijn machine dus een link naar die share, bv Z:\websites)
- Wil een developer werken aan een file dan opent hij sourcesafe explorer, selecteert de file, kiest edit. Sourcesafe explorer zal dan de file uitchecken in de working folder (dus de folder op de website) en de editor openen die geassocieerd is met de extensie. Dit is interdev.
- Men edit de file, savet deze en bij goed vinden van de wijzigingen checkt men hem weer in in sourcesafe dmv de sourcesafe client.
- anderen kunnen de file die is uitgecheckt niet editen, want normaliter staat sourcesafe geen multi-checkouts toe. DIt kun je wijzigen in de admin van sourcesafe, mocht je dat willen.

het voordeel is nu dat je hele sets van pagina's uit de ene site kunt delen in een andere site: je 'sharet' bv een compleet project in een ander project in de sourcesafe explorer. Wanneer een developer dan zo'n gesharede page edit, wordt deze automatisch gewijzigd in alle projects. Dit is makkelijk bv wanneer je een webclient hebt van een CMS of andere tool die vaker terugkomt in meerdere projecten. Je doet dan daarna een 'get latest version' voor alle projecten die de gesharede file hebben en klaar ben je.

Werkt erg goed hier. We gebruiken deze methode nu een jaar of 2 en heb absoluut geen spijt hiervan gehad. Verder werkt deze methode ook goed wanneer je mensen hebt werken aan je project die andere editors gebruiken, bv iemand die homesite gebruikt voor de HTML, want die werkt exact op dezelfde manier met de projecten als de andere developers.

In visual studio.net zijn de frontpage extensies ook vervangen door filesharing, ong. de methode die ik hierboven beschrijf alleen regelt visual studio de checkin/out en hoef je dat niet handmatig te doen. Dat is wellicht even lastig, maar dat went snel.

Succes

[ Voor 3% gewijzigd door EfBe op 24-12-2002 13:27 ]

[Scare360]

Let wel op:

Bij deze werkwijze kun je problemen verwachten als een modificatie in een shared file de code breekt in andere projecten. Vaak kom je hier pas achter als je bv een backup naar een klant stuurt of een doorontwikkeling doet op een project.

Ligt een beetje aan de methodiek van ontwikkelen binnen je onderneming.


Wij passen het volgende toe:

- alle files in VSS db op een centrale server, tevens webserver
- alle clients hebben een locale IIS server + VSS client
- alle projecten zijn fysiek zowel op de client als server in de workfolders gepubliceerd

De admin van de server doet een get latest version op milestones welke dan een label krijgen in VSS. Er wordt dus gewerkt op project niveau. Indien een gedeelde file, bv een mailscript over meerdere projecten gebruikt wordt voorzien wij deze van een label op moment van sharen. Indien code breekt bij andere klanten kunnen we dus een roll back doen tot een "stable state" van de code.

- editing in de lokale work folder van de client, testen op lokale server
- zodra aan de hand van functionele testen blijkt dat de zaak stabiel is kan die ingechecked worden
- zodra de server admin genoeg werk ontvangen heeft doet die een get latest version
- zodra het test team de site "ok" vind wordt de label versie van de milestone naar een productie server gebracht.

[EfBe]

paulgielens schreef op 24 december 2002 @ 13:51:
Let wel op:

Bij deze werkwijze kun je problemen verwachten als een modificatie in een shared file de code breekt in andere projecten. Vaak kom je hier pas achter als je bv een backup naar een klant stuurt of een doorontwikkeling doet op een project.
Ligt een beetje aan de methodiek van ontwikkelen binnen je onderneming.

Als dit in de mogelijkheden ligt, moet je de geen code 'sharen' natuurlijk. Je sharet alleen die code die ook gelijk kan zijn in alle projecten. Ik ging daarvan uit in mijn verhaal, maar inderdaad wel iets om rekening mee te houden.