[VS.NET] VSS, CVS of Subversion?

[GrimaceODespair]

Ik sta op het punt versiebeheer in te voeren op mijn werkplek, maar twijfel nog over de... euh... versie.

VSS
Een eerste logische keuze leek Visual SourceSafe, vanwege het MSDN-abbo dat we hebben. Gedachte: "als je eenmaal MS bezig bent, kun je beter MS aanhouden" + ik heb er al eens mee gewerkt, maar op een kleine codebase en met weinig mensen.

Als je echter iets als dit leest, sla je natuurlijk aan het twijfelen:

• corrupte db
• tergend traag
• irritante locking
• ...

CVS
Nu heb ik op mijn vorige werkplek CVS gebruikt icm de Igloo plugin voor Visual Studio 6. Dat werkte aardig, maar de grap was dat ik de enige was die source control gebruikte. Voor geavanceerde taken (zoals het opzetten van een module) haalde ik overigens WinCVS uit de kast.

Subversion
Via de link hierboven bood zich nog een 3e alternatief aan waarvoor ook een Visual Studio.NET plugin bestaat: Subversion. Dit versiebeheerpakket kende ik nog niet, maar aangezien het is opgezet door de makers van CVS om de manco's van zijn voorloper op te vangen, lijkt het mij wel een serieuze kandidaat. Ik weet echter niet hoe lekker die VS.NET plugin werkt.

---

Voorlopige conclusie
Ik zou graag voor Subversion gaan. Echter, ik kan me voorstellen dat de plugin nog niet lekker werkt in een productieomgeving. Dus voor de meeste zekerheid, kies ik voorlopig CVS/Igloo.

De vragen

• Heeft iemand bedenkingen bij mijn keuze?
• Zijn hier mensen met goede/slechte ervaringen met CVS/Subversion icm een VS plugin?
• Wat zijn ooit jullie argumenten geweest om wel of niet voor een bepaald versioning systeem te kiezen?

[mbravenboer]

GrimaceODespair: Wat zijn ooit jullie argumenten geweest om wel of niet voor een bepaald versioning systeem te kiezen?

Ik kan verder niets nuttigs zeggen over de integratie in VS .NET, maar als integratie in een IDE niet mee zou spelen, zou ik absoluut voor Subversion gaan. Een aantal voordelen op een rijtje die voor ons belangrijk zijn:

1. versie beheer van directories. Je kan directories manipuleren zoals je dat gewoon zou verwachten in een file systeem. Onder CVS is dit werkelijk verschrikkelijk en daardoor blijf je vaak geforceerd in een irritante structuur werken: het is lastig te corrigeren, zeker met behoud van history. Braching en tags zijn niets anders dan het kopieren van een directory.

2. Hergebruik van HTTP: Subversion biedt eigenlijk resources op het web onder versie beheer. Je kan dus de sources benaderen via normale tools die HTTP gebruiken (browsers dus ).

3. Atomaire commits

Met name punt 1 weegt voor mij enorm zwaar in het voordeel van Subversion. Subversion voor circa 0.25 was nog behoorlijk traag, maar de snelheid is enorm verbeterd in de laatste releases. Het schijnt dat ze overwegen om spoedig een 1.0 uit te brengen, wat gebruikers misschien een zekerder gevoel geeft.

[MSalters]

De vergelijking CVS en VSS is makkelijk. Er zijn twee redenen om CVS boven VSS te kiezen, prijs en UNIX support. Op alle andere gebieden verliest CVS.

Ik heb CVS 6 maanden gebruikt, en ik weet nog steeds niet of het mogelijk is om de files te zien die in de repository zitten. Waarschijnlijk doet iedereen hetzelfde als ik, inloggen op de server en dan "ls -lR /home/cvs/Repository".

De link suggereert dat VSS soms zijn history verliest. Ik geloof direct dat zoiets kan gebeuren op een Win95 box zonder UPS en met een crappy IDE schijf, maar ik heb nog nooit zoiets gehoord binnen ons bedrijf - NT, UPS en SCSI zijn stabiel genoeg.

mbravenboer haalt al directories aan. Zoek eens op internet hoe je in CVS een directory renamed. Zelfs een file renamen grenst al aan het waanzinnige in CVS.

Dat gezegd hebbende, ik weet dat VSS6 verre van perfect is. Microsoft zelf gelooft er niet heel erg in, heeft er al een tijd niet veel aan gedaan, en gebruikt zelf wat anders. Het is niet voor niets dat er veel alternatieven zijn. Ik hoor nog wel eens goede verhalen over ClearCase

[GrimaceODespair]

MSalters schreef op 18 januari 2004 @ 01:20:
De link suggereert dat VSS soms zijn history verliest. Ik geloof direct dat zoiets kan gebeuren op een Win95 box zonder UPS en met een crappy IDE schijf, maar ik heb nog nooit zoiets gehoord binnen ons bedrijf - NT, UPS en SCSI zijn stabiel genoeg.

Als je doelt op het stuk dat ik denk, dan bedoelde die gast eerder: omdat de database te groot en te traag werd, moest hij elke 6 maanden de boel opnieuw opzetten. Zo verloor hij dus telkens zijn history.

Maar verder is algemeen bekend denk ik dat VSS nu en dan zijn eigen db verneukt.

[curry684]

Ik heb met jarenlange productieervaring met VSS met echt enorme databases (tientallen gigabytes) nog nooit corruption of extreme traagheid bemerkt, ook niet in extreme multi-user omgeving. Enige wat je bij VSS in het achterhoofd moet houden is dat 'exclusive checkouts' een pre is, mergen is een rotzooi: maar dat geldt voor ieder systeem, alleen is VSS er notoir slecht in om het zelf te doen.

Overigens idd: MS gebruikt het zelf ook niet en het is al tijden niet meer bijgewerkt. Het is overigens ook geen eigen produkt (ze hebben het destijds ingekocht).

[GrimaceODespair]

curry684 schreef op 18 januari 2004 @ 01:50:
Ik heb met jarenlange productieervaring met VSS met echt enorme databases (tientallen gigabytes) nog nooit corruption of extreme traagheid bemerkt, ook niet in extreme multi-user omgeving.

Hmm... zou mijn link gesponsord zijn door de Open Source community (of curry door MS ) ? Gek dat de ervaringen zo ver uit elkaar liggen.

Overigens, via wat backward linking in Google kwam ik op deze pagina terecht, die een hele resem versioning systemen vergelijkt. Ik meld hem ook maar even for the record.

[EfBe]

Mensen die met VSS problemen hebben als trage databases en corrupte files hebben de manuals niet goed gelezen. Veelal zitten ze met gigabytes aan data in de database, checken ze megabytes aan binaries in (die geen versioning krijgen) en staat alles op de oudste butt-PC van de zaak met een gare hdd en erg weinig memory. Tja... Je sources zijn ook niet erg belangrijk, toch?

VS.NET heeft zelf een erg beperkte manier van koppelen met sourcecontrol systemen. Wat je ook gebruikt, het is behelpen. Whidbey wordt erg veel beter, tezamen met de opvolger van sourcesafe. Als je een solide sourcecontrol systeem wilt en dat goed met vs.net werkt en met je oude vss spullen overweg kan, kijk dan naar Vault van sourcegear (www.sourcegear.com).

[ Voor 4% gewijzigd door EfBe op 18-01-2004 11:45 ]

[MSalters]

GrimaceODespair schreef op 18 januari 2004 @ 03:11:
[...]
Hmm... zou mijn link gesponsord zijn door de Open Source community?

Eerste regels van de gelinkte pagina:

Following is a list of replies to my question regarding
Subversion vs Visual SourceSafe on the Subversion mailing list.

[GrimaceODespair]

MSalters schreef op 18 januari 2004 @ 15:02:
Eerste regels van de gelinkte pagina:

... had ik natuurlijk zelf kunnen bedenken ...

[igmar]

MSalters schreef op 18 januari 2004 @ 01:20:
De link suggereert dat VSS soms zijn history verliest. Ik geloof direct dat zoiets kan gebeuren op een Win95 box zonder UPS en met een crappy IDE schijf, maar ik heb nog nooit zoiets gehoord binnen ons bedrijf - NT, UPS en SCSI zijn stabiel genoeg.

De problemen met VSS zijn niet te wijten aan hardware of OS, maar aan VSS. Histories die corrupt raken, problemen de locking, versies die niet kloppen, de problemen met VSS zijn eindeloos.

mbravenboer haalt al directories aan. Zoek eens op internet hoe je in CVS een directory renamed. Zelfs een file renamen grenst al aan het waanzinnige in CVS.

Vrij problematisch inderdaad. Ik rename ze op de CVS server en doe dan een nieuwe checkout. Niet echt netjes, je history veranderd namelijk niet mee.

Dat gezegd hebbende, ik weet dat VSS6 verre van perfect is. Microsoft zelf gelooft er niet heel erg in, heeft er al een tijd niet veel aan gedaan, en gebruikt zelf wat anders. Het is niet voor niets dat er veel alternatieven zijn. Ik hoor nog wel eens goede verhalen over ClearCase

Ik ben zelf ook hard op zoek naar een CVS alternatief, zonder bestaande CVS projecten en histories te verliezen.

[mbravenboer]

igmar: Ik ben zelf ook hard op zoek naar een CVS alternatief, zonder bestaande CVS projecten en histories te verliezen.

Subversion kan natuurlijk CVS repositories importeren, met behoud van history.

[igmar]

mbravenboer schreef op 18 januari 2004 @ 16:01:
Subversion kan natuurlijk CVS repositories importeren, met behoud van history.

Inderdaad, die vergelijking was erg verhelderend. Ik ga het gewoon proberen, en indien dat successvol is converteer ik de rest en zet de CVS op read-only. CVS is steeds meer een beperking hier, en rechtstreeks de repository 'bewerken' is niet echt gewenst...

[EfBe]

igmar schreef op 18 januari 2004 @ 15:41:
De problemen met VSS zijn niet te wijten aan hardware of OS, maar aan VSS. Histories die corrupt raken, problemen de locking, versies die niet kloppen, de problemen met VSS zijn eindeloos.

Poepverhalen in ERG veel gevallen. VSS is geen makkelijk pakket, en source control is over het algemeen niet makkelijk op te zetten. Ik zie telkens weer situaties waarbij 3 man dezelfde file zitten te editen en dat ze dan raar opkijken dat het sourcecontrol systeem de merges soms niet goed doet. Denk dan na! Een betere scheduling van edits/werken aan files/projects is essentieel voor sourcecontrol.

Dus een opmerking als 'de problemen met VSS zijn eindeloos' zijn IMHO veelal op onzin gebaseerd, of iig op de verkeerde conclusie. Veelal is de belabberde hardware (de vss server is veelal een oude bak), mega grote databases met de meest gore temp projects en bin files die je maar kunt voorstellen en onkundig gebruik de oorzaak. Tja.

[igmar]

[b]EfBe schreef op 18 januari 2004 @ 16:44:[/b
Poepverhalen in ERG veel gevallen.

Ah ja, dus er lullen tientallen zoniet honderden mensen uit hun nek, en die zijn volgens jou allemaal erg dom ? Interessante bewering.

VSS is geen makkelijk pakket, en source control is over het algemeen niet makkelijk op te zetten. Ik zie telkens weer situaties waarbij 3 man dezelfde file zitten te editen en dat ze dan raar opkijken dat het sourcecontrol systeem de merges soms niet goed doet. Denk dan na!

Nee. Indien een merge niet gedaan kan worden behoort het pakket te klagen, en niet de zaken te verkloten. Ik heb liever dat iets niet gedaan wordt als niet goed. VSS doet het niet goed, met alle gevolgen van dien.

Een betere scheduling van edits/werken aan files/projects is essentieel voor sourcecontrol.

Da's de ene helft. De andere helft is dat merges consequent gedaan worden, en niet half.

Dus een opmerking als 'de problemen met VSS zijn eindeloos' zijn IMHO veelal op onzin gebaseerd, of iig op de verkeerde conclusie. Veelal is de belabberde hardware (de vss server is veelal een oude bak), mega grote databases met de meest gore temp projects en bin files die je maar kunt voorstellen en onkundig gebruik de oorzaak. Tja.

Ik heb de corrupte databases zelf meegemaakt, en op (grote) projecten waar echt geen binaries in zaten. Zelfs al is 10% op waarheid berust, dan nog zijn de problemen aanzienlijk. Het gaat niet altijd fout, maar het KAN wel fout gaan, met grote consequenties.

Mensen van MS Nederland raden het gebruik van VSS af, en dat geeft mij geen goed gevoel. En nee, ik noem geen namen.

[igmar]

igmar schreef op 18 januari 2004 @ 16:16:
Inderdaad, die vergelijking was erg verhelderend. Ik ga het gewoon proberen, en indien dat successvol is converteer ik de rest en zet de CVS op read-only. CVS is steeds meer een beperking hier, en rechtstreeks de repository 'bewerken' is niet echt gewenst...

Ik zal als ik de .src.rpm packages af heb wel effe een URL posten waar ik ze neergooi, ik moest toch al aan de gang ivm een nieuwe python versie

[Verwijderd]

Ik gebruik cvs en de CVS SCC plugin van pushok.
http://www.pushok.com/soft_cvs.php

Het is niet 100% zonder problemen, maar een heel stuk beter dan de igloo plugin.

[Creepy]

En kijk anders ook eens naar Arch en Perforce. Van Perforce weet ik dat er plugins te krijgen zijn voor de meest gebruikte IDE's. De automatische merge schijnt geweldig te zijn (en anders klaagt ie wel, en komt ie met een diff utility op de proppen om handmatig te mergen). Servers en clients te verkrijgen voor meerdere platformen.

Directories en files renamen met behoud van history is in Arch, Subversion en Perforce geen probleem.

[GrimaceODespair]

Verwijderd schreef op 19 januari 2004 @ 11:32:
http://www.pushok.com/soft_cvs.php

Hmmm, als ik de developers mag geloven is het inderdaad een flinke verbetering, op het Engels na

quote: http://www.pushok.com/soft_cvs_vsvss.php

Several different protocols exist: sequre/not sequre

Het kost trouwens maar 20$ per kopie. Lijkt me een serieuze kandidaat voor ons. tnx.

Verwijderd schreef op 19 januari 2004 @ 11:32:
Het is niet 100% zonder problemen, maar een heel stuk beter dan de igloo plugin.

Kan je aangeven wat voor soort problemen? (bugs, ongewenst gedrag, ...)

[ Voor 39% gewijzigd door GrimaceODespair op 20-01-2004 06:44 ]

[Verwijderd]

GrimaceODespair schreef op 20 januari 2004 @ 06:35:
Kan je aangeven wat voor soort problemen? (bugs, ongewenst gedrag, ...)

Vooral snelheid. Het is traag. Maar daar leer je wel mee leven.
Recursive check(out/in)s lost een hoop op.

We hadden een probleem met het inchecken van een setup project.
Na het verwijderen van alle binaire en tijdelijke bestanden, lukte het wel.
Daarna niet meer aan het project gezeten. Dus het kan nog problemen geven.

Verder is het gebeurd dat het project wat instellingen niet wilde vasthouden.
Maar dat kan ook liggen aan vs.net/scc provider.
De project file handmatig editten lostte dat ook op.

[GrimaceODespair]

Waarschuwing: oud topic!

(Dus, wildposters: lees draad voor je blaat)

For the record een status-update: we hebben CVSNT op Windows2003 Server geinstalleerd. Cliënt-side lossen we het op met de PushOK Plugin.

In eerste instantie leek de boel wel erg traag te draaien, maar daar bleek later een verkeerde dns-entry achter te zitten (contact leggen met server moest eerst langs een time-out). Nu dat opgelost is, draait de boel vrolijk met sspi.

Je vraagt je af en toe wel af waar PushOK nou mee bezig is, maar het blijft werkbaar qua snelheid.

Wel leek het op een gegeven moment overigens alsof de server de load niet meer aankon. Dat gebeurde toen ik een workspace met meer dan 10 projecten importeerde, terwijl een collega iets was aan het uitchecken. Zijn plugin deed vreemd, en mijn import faalde. Maar dat kan ook nog te maken hebben gehad met het feit dat ik de workspace al eerder verkeerd had ingecheckt

offtopic:
auw, die rode balk doet pijn aan mijn ogen

[ Voor 3% gewijzigd door GrimaceODespair op 03-02-2004 05:05 ]

[Janoz]

Als je met cvs werkt zou je ook kunnen kijken naar tortoise. Dit zorgt voor 'gekleurde mapjes' in explorer en extra opties in je context menu. Hierdoor is het werken met cvs (voor de gebruikers iig) een stuk makkelijker. Waar ik nu werk hebben we zelfs de grafische/html afdeling zover gekregen om cvs te gaan gebruiken . (Nu alleen nog even kijken hoe het te voorkomen is dat alle CVS directories mee worden geFTPd )

[igmar]

Janoz schreef op 03 februari 2004 @ 09:09:
(Nu alleen nog even kijken hoe het te voorkomen is dat alle CVS directories mee worden geFTPd )

Samba servers kunnen files veto'en, die zie je dus niet in je listings. Voor FTP servers geldt hetzelfde : Je kan sommigen vertellen dat CVS dirs niet geupload mogen worden.

Maar wat is het probleem van die CVS dirs ? Wij updaten gewoon op de servers zelf, en dan is de CVS info wel handig.

[GrimaceODespair]

Janoz schreef op 03 februari 2004 @ 09:09:
Als je met cvs werkt zou je ook kunnen kijken naar tortoise. Dit zorgt voor 'gekleurde mapjes' in explorer en extra opties in je context menu.

Ik heb dat ooit geïnstalleerd, maar wegens te traag van mijn systeem gebannen In de trade-off gebruiksvriendelijkheid vs snelheid heeft WinCVS toen gewonnen. Misschien is het er ondertussen op gebeterd hoor, maar ik vond de manier waarop die dialoogjes opkwamen hinderlijk in mijn productieproces

Janoz schreef op 03 februari 2004 @ 09:09:
Waar ik nu werk hebben we zelfs de grafische/html afdeling zover gekregen om cvs te gaan gebruiken

Ok, mag je mij uitleggen hoe je dat voor elkaar krijgt

[GrimaceODespair]

igmar schreef op 03 februari 2004 @ 09:34:
Maar wat is het probleem van die CVS dirs ? Wij updaten gewoon op de servers zelf, en dan is de CVS info wel handig.

Je bedoelt dat je repository=testomgeving=productieomgeving?

[igmar]

GrimaceODespair schreef op 03 februari 2004 @ 10:05:
Je bedoelt dat je repository=testomgeving=productieomgeving?

Zoiets

Op de productiebak gewoon een cvs co project, en draaien met die hap. Updaten van sites gaan hier met een cvs update commando.

Testomgeving is hier wel een aparte machine, maar dat maakt voor het CVS verhaal niks uit.

[Verwijderd]

Nu we het toch over versiebeheer hebben, is er iemand bekend met een goed versiebeheer programma voor (word) document?

[Verwijderd]

Het probleem met word documenten en versie beheer is dat word documenten binair zijn en de meeste versie beheer software alleen lekker werkt met text bestanden.

Bij binaire documenten slaat hij meestal elke keer het hele document op en je kan geen verschillen bekijken.

Ik heb wel gehoord van versie systemen die word ondersteunen, maar ik heb daar weinig vertrouwen in.
Als het om project documentatie gaan enzo zou ik eens kijken naar DocBook.

Doordat dat het DocBook formaat text gebaseerd is, heb je het probleem niet meer en kan je gewoon cvs of subversion gebruiken.

[djluc]

Verwijderd schreef op 04 februari 2004 @ 09:44:
Het probleem met word documenten en versie beheer is dat word documenten binair zijn en de meeste versie beheer software alleen lekker werkt met text bestanden.

Bij binaire documenten slaat hij meestal elke keer het hele document op en je kan geen verschillen bekijken.

Dit zou dus een goede mogelijkheid zijn als je Office hebt die in XML zijn data opslaat. Dan kan een bestaand versiebeheer programma er wel mee om gaan.

[Verwijderd]

In de basis wel ja.

Wil alleen eerst zien dat microsoft zo'n bestand een beetje stabiel houdt bij wijzigingen in het document. Maar ik neem aan dat dat wel los loopt.

[Creepy]

Van Perforce weet ik dat ze een plugin hebben voor Office, om zo vanuit Word of Excel rechtstreeks de opties te hebben voor in/uit checken, bewerken e.d. van de office documenten in perforce. JE kan zelfs vanuit WOrd bijv. de verschillen zien tussen 2 documenten. Zie ook http://www.perforce.com/p...ducts/plugins-ofcss3.html