Problemen met VSS, alternatief gezocht.

[whoami]

Problemen met Visual Sourcesafe

Vandaag heb ik op 't werk een onaangename verrassing gehad met Visual Sourcesafe. M'n Visual Studio.NET crashte; geen probleem, opnieuw opstarten, en opnieuw inloggen in m'n project. Dat laatste was echter niet zo vanzelfsprekend.
Ik kreeg eerst de foutmelding dat het bestand srcsafe.ini niet kon gevonden worden. Ff kijken, en idd, dat bestand was nergens te bespeuren, evenals users.txt trouwens.
(Ik denk niet dat het crashen van VSNET gerelateeerd is aan het corrupt worden van VSS, aangezien ik dat (crashende vs.net) al meerdere keren gehad heb).

Ik heb toen maar die bestanden even uit een backup opgevist, maar daarmee waren de problemen nog niet van de baan. Ik kreeg toen foutmeldingen als file 'aaaaaaa' not found, etc....
Dan maar geopteerd voor de korte pijn: de backup van vrijdag laten terugzetten. Dat was ook niet vanzelfsprekend, aangezien er een fout optrad: 'Inconsistency found on the medium'.
Nu moet ik het dus doen met de back-up van donderdag....

Goed, na wat overwerk is alles nu bijna ongeveer weer in orde, echter, ik wil dit geen 2de keer meemaken. Aangezien het bekend is dat een VSS db soms wel eens corrupt wil worden, heb ik maar besloten om VSS te ditchen.
Nu heb ik 2 alternatieven: of ik ga Subversion gebruiken, of ik ga gebruik maken van Sourcegear's vault.

Iemand die ervaringen heeft met een van beide systemen ? Ik lees dat Subversion integreert met VS.NET (mits een plug in), en ik heb gehoord dat Vault eigenlijk niet zo best - of zelfs niet - integreert met VS.NET.
Mijn voorkeur zou dus uitgaan naar Subversion, maar ik had graag toch enkele gebruikerservaringen gesprokkeld.

[Robtimus]

Geen ervaring mee, maar zowel Subversion als CVS hebben 3rd party plugins waarmee je het integreert in Windows.

[D4Skunk]

svn heeft m'n voorkeur..., sourcegear heb ik nooit gebruikt...

Even wat motivatie : svn is een open standaard, en is volledig te scripten, en op bijna elk platform beschikbaar, met superveel rand-applicaties...

[ Voor 57% gewijzigd door D4Skunk op 06-03-2006 22:00 ]

[Thyraon]

Ik gebruik al een tijdje Subversion (SVN), en het bevalt me supergoed. Het is niet alleen handig als je met meerdere mensen aan een project werkt (iedereen die meewerkt kan bij de source), maar het leent zich ook prima als je in je eentje een klus doet (je hebt een online backup van je code, je kan eventuele wijzigingen ongedaan maken, en je kan makkelijk nagaan wat je al hebt gedaan en nog moet doen).

Om het gebruik van Subversion nog makkelijker te maken, gebruik ik zelf de TortoiseSVN-plugin in Windows, waardoor ik gewoon een grafische interface op SVN heb, geïntegreerd in mijn Windows-shell.
In het kort: ik kan rechts klikken in een willekeurige map, en meteen alle SVN-commando's uitvoeren met een klik van de muis.

Nog een handige tool als uitbreiding op SVN (hoewel ik niet weet of je dat nodig hebt), is trac, een stukje software dat op o.a. Apache-webservers kan draaien, waarmee je je projecten kan plannen d.m.v. Milestones en tickets.
Een andere mooie feature van trac is dat je de broncode van je projecten online kan bekijken, waarbij je alle code kan vergelijken met vorige revisions (een diff-viewer dus).
Ik maak hier zelf veel gebruik van omdat ik aan een project werk met iemand die in west-Nederland woont, terwijl ik zelf in België zit.

[.oisyn]

Als je een alternatief voor sourcesafe wilt zou ik echt Perforce aanraden. Het komt met visual studio integratie en het checkin concept is hetzelfde als met sourcesafe (itt cvs en svn, die een 'keep checked out' methode hanteren). Ik vind de manier van branchen echt ideaal, een branch is in feite gewoon een kopie naar een andere directory. Het integreren van sourcefiles tussen de branches is door die directories ook heel simpel te doen. En dmv client mappings kun je precies bepalen hoe het depot op je lokale directorystructuur gemapt is.

't Kost wel wat, maar je kunt het gratis gebruiken voor max 2 users en 5 clients

Oh, en 't wordt ook heel veel gebruikt in de gameindustrie, en die stellen meestal veel zwaardere eisen dan reguliere IT companies

[ Voor 10% gewijzigd door .oisyn op 07-03-2006 00:38 ]

[whoami]

k gebruik al een tijdje Subversion (SVN), en het bevalt me supergoed. Het is niet alleen handig als je met meerdere mensen aan een project werkt (iedereen die meewerkt kan bij de source), maar het leent zich ook prima als je in je eentje een klus doet (je hebt een online backup van je code, je kan eventuele wijzigingen ongedaan maken, en je kan makkelijk nagaan wat je al hebt gedaan en nog moet doen).

Ja, gelukkig maar. Hetgeen jij opsomt zijn natuurlijk de dingen waar ieder SourceControl systeem moet aan voldoen.

Ik zal ook eens even naar Perforce kijken.

[maikel]

whoami schreef op maandag 06 maart 2006 @ 21:17:

Iemand die ervaringen heeft met een van beide systemen ? Ik lees dat Subversion integreert met VS.NET (mits een plug in), en ik heb gehoord dat Vault eigenlijk niet zo best - of zelfs niet - integreert met VS.NET.

Ik heb een hele tijd gewerkt met SourceGear Vault en deze integreert goed met VS.Net hoor. Er is geen verschil merkbaar tussen Vault en SourceSafe.
Wel was het in mijn geval zo dat we op dat moment (nog) alleen een single-user license hadden, waardoor het niet duidelijk was wie welk bestand had uitgecheckt.

Ook het branchen e.d. zitten er allemaal in.

En SourceGear heeft een cool promo-filmpje voor Vault gemaakt!

[ Voor 4% gewijzigd door maikel op 07-03-2006 09:37 ]

[Thyraon]

whoami schreef op dinsdag 07 maart 2006 @ 08:54:
[...]

Ja, gelukkig maar. Hetgeen jij opsomt zijn natuurlijk de dingen waar ieder SourceControl systeem moet aan voldoen.

Daar heb je een punt .

[H!GHGuY]

Ik ben een happy TortoiseSVN gebruiker (geen IDE integratie, enkel verkenner-integratie)
behalve SVN heb ik enkel een minieme ervaring met CVS (TortoiseCVS) en ik vind het balen.

Ik moet je wel aanraden om van SVN even de manual te lezen voor je begint.
Het systeem van branches etc ligt net iets anders dan bij CVS afaik. Ik gebruik SVN dan ook alleen (meer om mijn verschillende PC's/werkplaatsen gesynchroniseerd te houden) en kan niet echt zeggen hoe het performed tov meerdere users. Er zit echter wel een visueel diff programma in afaik.

[chem]

SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

De setup is dat er een H:\ drive is naar de server-home dir met daar de checkout, en een 2e server waar svn draait. Committen heeft dus 3 machines nodig, maar de netwerkkaart doet niet meer dan een halve mbit op zo'n moment. Vreemd dus.

---

Wel moet ik zeggen dat het verder fijn werkt, vaak een stuk beter/logischer dan CVS.

[ Voor 8% gewijzigd door chem op 07-03-2006 11:50 ]

[kenneth]

Wij gebruiken SVN Met een SCC Proxy (die van PushOK).
Maar committen vanuit VS.NET zorgt voor meerdere commits (1 per project ofzo).
Dus nu doe ik het weer met TortoiseSVN, ik heb graag 1 commit per issue.

Dus ik zou ook even goed kijken hoe die integratie loopt. Er zijn nog andere plugins.

[Nick_S]

.oisyn schreef op dinsdag 07 maart 2006 @ 00:36:
Het komt met visual studio integratie en het checkin concept is hetzelfde als met sourcesafe (itt cvs en svn, die een 'keep checked out' methode hanteren).

Maakt VSS juist geen gebruik van Keep checked out, (Check out, werk eraan, check in) itt. tot cvs en svn die via een update, werk eraan, update, commit manier werken?

[.oisyn]

chem schreef op dinsdag 07 maart 2006 @ 11:50:
SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

Tja ik kom nu vast over als een zealot, maar wederom: perforce . Wij hebben er nu 5 games in staan, plus nog alle branches van de huidige game van de individuele personen. Om je een idee te geven, Tomb Raider Legend is bij mij op disk 120 GB in 200.000 files, en dan heb ik nog niet eens de hele directorytree.

Nick_S schreef op dinsdag 07 maart 2006 @ 12:50:
[...]

Maakt VSS juist geen gebruik van Keep checked out, (Check out, werk eraan, check in)

Zoals je het zelf al zegt is dat geen keep checked out, aangezien je het incheckt zodra je ermee klaar bent . Er zitten natuurlijk zowel nadelen als voordelen aan beide methoden.

[ Voor 59% gewijzigd door .oisyn op 07-03-2006 13:25 ]

[matthijsln]

chem schreef op dinsdag 07 maart 2006 @ 11:50:
SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

De setup is dat er een H:\ drive is naar de server-home dir met daar de checkout, en een 2e server waar svn draait. Committen heeft dus 3 machines nodig, maar de netwerkkaart doet niet meer dan een halve mbit op zo'n moment. Vreemd dus.

Lijkt me dan toch aan je netwerk configuratie en niet aan SVN te liggen dat het traag is. Hier is SVN redelijk snel (zelfs over internet met SSH tunnels, ongeveer de traagst mogelijke manier) en schaalt goed (~0.5 gb repository, fsfs backend).

[ Voor 8% gewijzigd door matthijsln op 07-03-2006 13:32 ]

[igmar]

chem schreef op dinsdag 07 maart 2006 @ 11:50:
SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

da's denk ik bdb gerelateerd. Dies altijd rete traag, en heeft de vervelende neiging wel eens corrupt te raken als een user dingen afbreekt. Ik draai hier al tijden fsfs, en tot nu toe probleemloos.

[MSalters]

chem schreef op dinsdag 07 maart 2006 @ 11:50:
SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

De setup is dat er een H:\ drive is naar de server-home dir met daar de checkout, en een 2e server waar svn draait. Committen heeft dus 3 machines nodig, maar de netwerkkaart doet niet meer dan een halve mbit op zo'n moment. Vreemd dus.

---

Wel moet ik zeggen dat het verder fijn werkt, vaak een stuk beter/logischer dan CVS.

Dat klinkt nodeloos ingewikkeld. Waarom heb je een sandbox op je server? Een sandbox hoeft niet gebackuped te worden, en de compiler wordt ook niet blij van files op de server (latency).

Overigens heeft Perforce een ontzettend irritante beperking. Een undo of revert zit er niet in. Als je dus #5 incheckt, en je bendenkt later dat #4 toch beter was, dan is de oplossing in de praktijk om #4 op te halen, te kopieren, #5 uitchecken en #4 eroverheen te kopieren. Dat is dus dikke ellende als het om een paar files gaat.

[.oisyn]

Beetje omslachtig, je kunt ook gewoon #4 uitchecken, syncen en dan accept yours doen bij het resolven. Bovendien is het goed te doen met wat custom scripts.
En revert zit er weldegelijk in.

[ Voor 91% gewijzigd door .oisyn op 07-03-2006 14:24 ]

[Nick_S]

.oisyn schreef op dinsdag 07 maart 2006 @ 13:13:
[...]

Zoals je het zelf al zegt is dat geen keep checked out, aangezien je het incheckt zodra je ermee klaar bent . Er zitten natuurlijk zowel nadelen als voordelen aan beide methoden.

Ok, maar dan maken CVS en SVN toch ook geen gebruik van Keep checked out? Daar check je zelfs helemaal niets uit, maar gaat pas kijken of je wel de laatste versie hebt op het moment van committen. (Volgens mij zitten er wel locks in, maar dat is vziw niet de standaard manier van werken)

[.oisyn]

Bij CVS check je out op het moment dat je synct. Ik vind het een irritant systeem omdat je niet weet wie er allemaal nog meer met die file bezig is, en dat je niet op de hoogte wordt gesteld als je niet met de laatste revisie bezig bent (omdat je niet eerst hoeft uit te checken). Het voordeel is wel dat je makkelijker offline kunt werken.

[ Voor 25% gewijzigd door .oisyn op 07-03-2006 14:28 ]

[kenneth]

Vziw kent SVN ook nog geen rollbacks (wel atomic commits gelukkig).
SVN biedt ook locks, waardoor je nog wel kan voorkomen dat je met z'n tienen een onmogelijke merge aan het veroorzaken bent.

[giMoz]

Om deze toch maar een kleine kick te geven..

Er worden nogal wat alternatieven gegeven hier maar geen van allen zouden echt goede alternatieven zijn voor VSS, dit vanwege de intergratie met Visual Studio (6/2003/2005) en het "Keep checked out".

een source control systeem wat die 2 heeft, en benaderbaar is via internet zou voor mij een goede oplossing zijn.

[djc]

chem schreef op dinsdag 07 maart 2006 @ 11:50:
SVN performance is hier om te janken. Het is echt zielig traag, wellicht door het grote aantal bestanden en mappen dat we hebben (ruim 3300 files), maar het irriteert wel. Een commit op de server met svn commit is in een seconde of wat klaar, de windows-bakken zijn enkele minuten bezig soms.

De setup is dat er een H:\ drive is naar de server-home dir met daar de checkout, en een 2e server waar svn draait. Committen heeft dus 3 machines nodig, maar de netwerkkaart doet niet meer dan een halve mbit op zo'n moment. Vreemd dus.

In dit soort gevallen vormt je I/O de bottleneck. Sowieso blijkt vaak op de svn-dev lijst dat de performance van Windows' filesystemen een grote bottleneck vormt bij checkout uit Subversion. Het is natuurlijk ook een beetje vreemd dat je uitcheckt naar een netwerk-schijf... Als je dat niet zou doen gaat het waarschijnlijk een stuk sneller (Subversion neemt juist aan dat lokale access snel is, en er werd dan ook tot voor kort niet erg beknibbeld op lokale schijf-access; IIRC zijn er in 1.4 release of zelfs al in 1.3 een aantal verbeteringen hiervoor te verwachten).

Mijn ervaringen met Subversion zijn in ieder geval prima.

[ Voor 4% gewijzigd door djc op 28-03-2006 08:47 ]

[whoami]

giMoz schreef op dinsdag 28 maart 2006 @ 08:12:
Om deze toch maar een kleine kick te geven..

Er worden nogal wat alternatieven gegeven hier maar geen van allen zouden echt goede alternatieven zijn voor VSS, dit vanwege de intergratie met Visual Studio (6/2003/2005) en het "Keep checked out".

een source control systeem wat die 2 heeft, en benaderbaar is via internet zou voor mij een goede oplossing zijn.

Volgens mij is dat mogelijk me Vault. Ik heb er even mee gespeeld (je kan een 'gratis' versie downloaden, maar die is maar bruikbaar voor 1 persoon, dat is niet voldoende voor m'n project), en dat ziet er wel goed uit.
Helaas pindakaas wordt er blijkbaar geen gehoor gegeven hier @work aan m'n voorstel...

[giMoz]

Denk dat $289 per user ook een beetje buiten mijn budget ligt...

zijn er gratis versies verkrijgbaar??

[ Voor 5% gewijzigd door giMoz op 28-03-2006 09:46 ]

[whoami]

giMoz schreef op dinsdag 28 maart 2006 @ 09:45:
Denk dat $289 per user ook een beetje buiten mijn budget ligt...

zijn er gratis versies verkrijgbaar??

Wat is 289$ voor een beursgenoteerd bedrijf....

Zoals ik al zei, zijn er gratis versies verkrijgbaar voor één user.

[giMoz]

wie had het over een beursgenoteerd bedrijf, tis voor prive wat mensen die samen .net software willen ontwikkelen

[kenneth]

Tsja, is SVN dan echt zo'n probleem?

intergratie met Visual Studio (6/2003/2005)

PushOK SVN proxy, AnkhSVN, e.v.a.

en het "Keep checked out".

Is een manier van werken. Persoonlijk vind ik keep checked out i.c.m. mergen prettiger dan check out/check in. Daarbij ondersteunt SVN locking, dus daar kan je ook nog mee aan de gang.
Het lijkt me iets waar je overheen moet kunnen komen als het voor privégebruik is en het ook nog eens geen/weinig geld moet kosten?

[whoami]

giMoz schreef op dinsdag 28 maart 2006 @ 10:30:
wie had het over een beursgenoteerd bedrijf, tis voor prive wat mensen die samen .net software willen ontwikkelen

Jij had het over 'ook', ik heb dit topic in een andere context gestart, en nu terug on topic aub.

[Verwijderd]

deze link kan je misschien op de nadelen van SVN duiden:

http://svn.haxx.se/users/archive-2005-07/0287.shtml

als je uitgebreid branching nodig hebt in een groot team. (Clearcase is hier nog niet vernoemd, maar heeft ook een integratie voor VS.NET).
Wij draaien hier Clearcase LT voor een J2EE project en hebben ook geen problemen, dus misschien ook de moeite van het onderzoeken waard....

De link leek me vooral interessant omdat het de eerste maal is dat ik eenuitgebreide review las van Subversion incl. nadelen die niet onbelangrijk zijn voor grote projecten.

[BCC]

Trac (SubVersioN, Wiki, bugtrac etc) is echt heerlijk om projectjes te ontwikkelen met meerdere mensen. Heb je daar al naar gekeken?

[chem]

MSalters schreef op dinsdag 07 maart 2006 @ 13:52:
[...]

Dat klinkt nodeloos ingewikkeld. Waarom heb je een sandbox op je server? Een sandbox hoeft niet gebackuped te worden, en de compiler wordt ook niet blij van files op de server (latency).

Er is 1 server met apache/php/mysql etc.; we hebben niet 15 verschillende setups voor elke developer. Dat zou buitensporig veel onderhoud kosten om alle versies gelijk te houden (afgezien van de ellende die windows an sich al is als server).

[MSalters]

Nou begrijp ik 'm weer niet. Hoe heb je een probleem met versies gelijk houden? Dat is nou net het doel van een VS, om versies gelijk te houden +/- datgene waar je aan werkt.

Overigens, is een Terminal Server geen optie? Dan blijft je file I/O "lokaal" op de dev server. Development heeft meestal niet zulke hoge eisen aan de GUI, zeker niet als je toch al op de server moet testen. Bovendien heb je het voordeel dat je de CPU capaciteit beter gebruikt bij compileren (want hoe vaak gebeurt het dat alle developers tegelijkertijd compileren?) _{alhoewel dat voor interpreted en JIT dingen natuurlijk weer niet boeit}

[chem]

De versies van php/mysql/apache gelijk houden bedoel ik

Daarbij gaat het dus om webdevelopment, met compilen etc heb ik niks te maken.

Al onze productie bakken draaien linux, dus een windows-omgeving gebruiken voor development zorgt alleen maar voor problemen, omdat windows zo weinig kan icm php.

[SpamLame]

whoami schreef op maandag 06 maart 2006 @ 21:17:
Problemen met Visual Sourcesafe

Goed, na wat overwerk is alles nu bijna ongeveer weer in orde, echter, ik wil dit geen 2de keer meemaken. Aangezien het bekend is dat een VSS db soms wel eens corrupt wil worden, heb ik maar besloten om VSS te ditchen.
Nu heb ik 2 alternatieven: of ik ga Subversion gebruiken, of ik ga gebruik maken van Sourcegear's vault.

Valt me op dat nog niemand je gewezen heeft op de VSS admin tool die de VSS DB in 1 backup bestand (*.ssa) kan dumpen. Spreekt voor zich dat je wel moet zorgen dat dat bestand wel op tape of iets komt.
Projekten (of delen daarvan) terugzetten via een filesystem backup (dus de AAAAAA whatever mapen en bestanden) is iets wat niet aangeraden wordt (althans in de training die ik over VSS heb gehad).

Toegegeven dat VSS de database om zeep kan helpen (als dan niet geholpen door gebruikers),
maar met een regelmatige dump van de database met ssarc.exe en analyze (beide al dan niet gescript), voorkom je een hoop ellende.

[bloody]

Verwijderd schreef op vrijdag 31 maart 2006 @ 10:39:

Wij draaien hier Clearcase LT voor een J2EE project en hebben ook geen problemen, dus misschien ook de moeite van het onderzoeken waard....

Misschien leuk om te vermelden dat er ook mega goede integratie met clearquest (bugtracking tool) inzit.
Het is wel te hopen dat de plugin voor vs.net even goed is als die voor Eclipse, want cc heeft echt 1001 command line tools (laat staan de cleartool ).
Dan is er nog de prijs: reken op zo'n 2000 € per floating licensie (voor clearcase alleen), bovendien moet er flink worden geinvesteerd in een brute server bak.

[cvs79]

Nou, ik werk hier met Clearcase en VS.NET 2003 en ik vind het persoonlijk nog trager en vager werken als VSS. Tevens ziet clearcase af en toe niet dat er een nieuwe versie van een file is en blijf je dus zonder dat je t weet 3 weken met een oude file werken. Dit ondanks dat je update view doet. Voor een tool die zoveel kost vind ik het niet brengen wat je zou verwachten.

[Verwijderd]

cvs79 schreef op dinsdag 04 april 2006 @ 13:11:
Nou, ik werk hier met Clearcase en VS.NET 2003 en ik vind het persoonlijk nog trager en vager werken als VSS. Tevens ziet clearcase af en toe niet dat er een nieuwe versie van een file is en blijf je dus zonder dat je t weet 3 weken met een oude file werken. Dit ondanks dat je update view doet. Voor een tool die zoveel kost vind ik het niet brengen wat je zou verwachten.

Wij hebben Clearcase LT en 'reserved checkouts' waardoor het gewoon onmogelijk is om op een oude versie te werken (tenzij op een hijacked file, maar daar moet je moeite voor doen).

Ik weet niet wat er verschillend is aan de normale Clearcase, maar kun je geen reserved checkouts meer aanzetten?

En door die LT moet onze serverbak ook niet zo overdreven zwaar zijn. We hebben tot voor kort nog CC op NT4 gedraaid zelfs.