[VSS / CVS] Source Control Management

[Verwijderd]

Ik ben benieuwd hoeveel mensen zelf werken met source control management (SCM) tools en welke manier je dan gebruikt.

Wat ik bedoel met 'manier' van SCM:
Tot nu toe heb ik bijna altijd gewerkt met het principe 'checkout-en-lock', oftewel: als we in een team aan het ontwikkelen zijn, en je wil coderen in een bepaald bestandje, dan 'lock' je het bestand door het uit te checken. Andere developers kunnen er dan niet meer bij.

In mijn hele loopbaan (nu zo'n 10 jaar) heb ik bij veel bedrijven gewerkt en heb nog nooit gezien dat er gewerkt wordt met de 'andere' manier, namelijk de edit-merge-commit methode. Ben het alleen maar tegengekomen bij sourceforgeprojecten eigenlijk.

Een goede toelichting van wat ik bedoel met het verschil is [url=http://http://software.ericsink.com/scm/scm_checkins.html]hier[/url] te vinden.

Mijn vraag: werk jij op het werk wel met de edit-merge-commit methode en hoe bevalt het? Loop je ook wel eens tegen de 'checkout-lock' methode aan met je collega's en hebben jullie er richtlijnen voor bedacht?

[ Voor 4% gewijzigd door Verwijderd op 27-08-2006 19:05 ]

[H!GHGuY]

Bij ons op het werk wordt ge-edit en ge-merged.

voor er een build gemaakt wordt gaat een mail rond die aangeeft dat iedereen moet committen voor de commit stop. Na de commit stop kan iedereen lustig verder doen.

Soms wordt ook een chainmail opgesteld. Iedereen update, merget en commit dan zijn changes en zend de mail door naar de volgende. Dit voorkomt dat je 5 keer opnieuw moet mergen.

Ik heb de indruk dat dit systeem naar behoren werkt. Het developer team telt een 20-tal mensen.

[CyBeR]

Ik heb 't nog nooit op jouw 'checkout-en-lock' manier gedaan.. Bij CVS en SVN checkout je een hele tree, die edit je waar je wilt en je edits commit je. Anderen doen hetzelfde. Als je wilt commiten en iemand anders heeft dat ook al gedaan (dus dezelfde files ge-edit) dan moet je eerst je tree updaten, eventuele conflicts resolven en daarna alsnog committen. Conflicts kom ik zelf eigenlijk nooit tegen. Komt mischien door kleinere hoeveelheden mensen.

[ Voor 5% gewijzigd door CyBeR op 27-08-2006 19:09 ]

[whoami]

Dit hoort eerder thuis in Development Tools & Environments , ipv in PRG.
Het gaat nl over het werken / gebruik van devtools, en niet zozeer over het programmeren an sich.

PRG - > DT&E

[ Voor 4% gewijzigd door whoami op 27-08-2006 19:10 ]

[Gerco]

Ik heb het beide gedaan en ik merk dat veel mensen die lock-edit-unlock gewend zijn, maar moeilijk kunnen omgaan het checkout-edit-merge. Mijzelf maakt het niet zoveel uit, maar ik hoor wekelijks mensen schelden op SVN omdat er een conflict is en ze niet begrijpen waarom.

Ik denk dat er in de praktijk weinig verschil is als je mensen hebt die met de gebruikte methode kunnen omgaan. Helaas vinden veel mensen het teveel moeite om het checkout-edit-merge systeem te leren gebruiken en beperken ze zich tot schelden als het niet werkt zoals SourceSafe.

In grotere teams waarbij iedereen overal aan (kan) werk(t/en), werkt m.i. checkout-edit-merge beter. In kleine teams met afgebakende gebieden, kun je net zo goed lock-edit-unlock'en. Dat is in die andere situatie niet te doen.

[whoami]

Om even ontopic te gaan.
Ik werk al geruime tijd op 't werk met Visual Sourcesafe. Daar heb je iig de mogelijkheid edit/merge niet.
Zoals je hier kunt lezen, heb ik op een mooie dag eens problemen gehad met VSS.
Ik ben toen eens naar een aantal andere tools gaan kijken; ondermeer Subversion. Ik had al veel positieve commentaren over Subversion gehoord, maar om eerlijk te zijn, vond ik het een beetje een karwei om het goed op te zetten. De edit-merge methode heb ik ook eens uitgetest, maar ik ben er geen fan van. Ik heb liever de zekerheid van de 'lock/edit' methode (checkout/checkin).
Ik vind het nogal een raar idee dat het 'moet' mogelijk zijn om met meerdere mensen aan eenzelfde file te werken. Ik bedoel: als het werk goed georganiseerd is, dan moet dit toch vrijwel nooit voorkomen dat er 2 of meer mensen tegelijkertijd wijzigingen aan eenzelfde file moeten doen ?

Voor m'n privé projecten thuis gebruik ik nu zowiezo SourceGear's Vault. Daar heb je iig de keuze of je nu checkin/checkout wilt werken, of edit/merge.

[kenneth]

Edit/merge hier (svn), en dat bevalt goed. Klein team (2-3 man), dat wel.
Het is ook gewoon persoonlijke voorkeur: conflicten zijn doorgaans zeldzaam, terwijl locken iedere keer moet gebeuren.

Maar de gouden regel is dat scm geen excuus is om niet meer te communiceren

[Gerco]

whoami schreef op zondag 27 augustus 2006 @ 19:15:
De edit-merge methode heb ik ook eens uitgetest, maar ik ben er geen fan van. Ik heb liever de zekerheid van de 'lock/edit' methode (checkout/checkin).
Ik vind het nogal een raar idee dat het 'moet' mogelijk zijn om met meerdere mensen aan eenzelfde file te werken.

Het is ook niet dat er mensen aan dezelfde file moeten werken, maar meer dat het mogelijk moet zijn om zinvol je werk te doen zonder constant met de server in verbinding te staan. In een lock-edit-unlock systeem kun je nooit offline aan een nieuwe file gaan werken, want je kunt die file niet locken. Bij edit-merge heb je daar geen last van en kun je lokaal gewoon doen waar je zin in hebt.

In projecten met veel developers of projecten waarbij niet alle developers even actief zijn, is lock-edit-unlock eerder een hindernis dan handig. In een bedrijfssituatie is dat meestal geen probleem, maar bij open source projecten vaak wel.

[ Voor 5% gewijzigd door Gerco op 27-08-2006 19:25 ]

[Brainstorm]

Op mijn werk zijn we een maand of 2 geleden van Sourcesafe overgestapt naar Subversion. Het checkout & lock principe werkte voor ons meestal wel goed, aangezien maar 2-4 gebruikers tegelijkertijd bezig zijn aan hetzelfde project. Zolang je je code goed structureerd en met weinig personen werkt is inderdaad vrijwel altijd maar 1 gebruiker tegelijk aan een file bezig. Wel gebeurde het bij ons af en toe dat een tweede gebruiker toch echt bij een file moest en dan krijg je soms wel nare problemen. Die tweede gebruiker moet dan of wachten, of aan de eerste gebruiker gaan vragen om die file in te checken (wil je niet, kan de build breken) of om Sourcesafe heen werken. Geen van drie is echt gewenst, het tweede werd echter vaak gedaan. Met eventuele bijkomstige problemen.

Er waren verschillende redenen voor ons dat we naar Subversion over zijn gestapt, en edit-merge-commit is indirect 1 van de redenen. Primaire redenen waren:
* Performance verbetering. We werken met gegenereerde code, waardoor veel (relatief kleine) code files ontstaan. Als een gebruiker bijvoorbeeld opnieuw de DAL wil genereren, checkt hij heel die directory (en alle onderliggende) uit, maakt zijn wijzigingen en checkt de boel in. Je bent dan echter wel bijna dubbel zo lang bezig als wanneer je (net zoals in Subversion) het uitchecken geheel kan skippen en meteen naar het genereren kan overgaan. Als je dan met 1000+ files bezig bent, is dit wel erg prettig. Tevens lijkt Subversion ook gewoon sneller te zijn met operaties zoals inchecken.
* Betere backup mogelijkheden. Sourcesafe heeft het meerdere malen geflikt om zijn database inconsistent achter te laten als een gebruiker tijdens het inchecken crasht. We kunnen dan wel een check en een repair uitvoeren, toch zijn we in 1 geval code kwijt geraakt (gelukkig maar weinig). In Subversion maken we met een script regelmatig een hotcopy.
* Betere branching, alhoewel we hier nog nauwelijks gebruik van maken.

Over het algemeen vinden we Subversion nu prettiger werken. Omdat we primair in C# / ASP.NET werken en Visual Studio 2005 gebruiken, hebben we Tortoise SVN om SVN mee te gebruiken. Het is wel prettig dat dit met explorer integreert, zodat je aan het icoontje meteen de status (edit/conflict/ok/etc) van je code kan zien. Daarnaast gebruiken we Ankh om vanuit Visual Studio ook SVN te gebruiken, maar dit is toch wel een beetje een buggy.

[pjonk]

Ik heb ook beide systemen gebruikt. Eerst SourceSafe bij een klein bedrijf. Op zich ging dat best redelijk, maar ook wel ergernissen meegemaakt.
Bijvoorbeeld het vergeten in te checken van je sources op vrijdagmiddag waardoor je collega die in het weekend aan het project wil werken die file niet meer mag editten. Ook leidt deze werkwijze snel tot check-ins van code die nog niet af is of zelfs niet compileert.

Momenteel gebruik Subversion in een redelijk groot bedrijf. Het omschakelen naar edit / merge / commit was niet echt een probleem voor mij en ik zie nu een hoop voordelen van deze methode.
Zeker als je professioneel te werk gaat met branches/trunks en tags is SVN erg goed. Ik denk dat deze werkwijze in SourceSafe niet lekker werkbaar is.

[Verwijderd]

Bedankt voor de reacties tot dusver.

Op mijn werk gebruiken we dus sourcesafe met de checkout-lock methode. Afgelopen week wilde men dat we erg snel een oplevering zouden doen van (voor het verhaal even makkelijk) een webservice met zes methods.

We hadden drie man paraat en wilden het liefst tegelijk in dezelfde files kunnen werken waarbij de werkverdeling vrij makkelijk gemaakt was: elke coder moest twee van de zes methods gaan bouwen.

Wat we gedaan hebben is van alle classen waar we in moeten gaan werken, drie bestandjes gemaakt (Bijvoorbeeld: classFactoryPiet, classFactoryKlaas, classFactoryJan) en elk bestandje bevat een 'partial class'. We werken in C# en die biedt die mogelijkheid van partial classes die je kan scheiden over verschillende files, maar dit kan vast ook in andere talen dus maakt voor het verhaal niet uit.
Hiermee werd het principe van checkout-lock in ere gehouden. We konden fijn onze eigen bestandjes locken. Als we allemaal klaar zijn, voegen we de partial classes waaraan we alle drie werken gewoon samen in 1 bestand per class.

Pas later deze week kwam ik er achter dat hier het edit-merge-commit principe ook prima zou hebben gewerkt. Sterker nog, dat zou ons het samenvoegen van het werk aan het eind schelen.
Ik moet toch eens die edit-merge-commit methode aan ons projectteam gaan voorstellen geloof ik

[djc]

Overigens wil ik graag opmerken dat ook Subversion de mogelijkheid biedt op (een deel van) je files een lock te eisen, zodat je effectief een lock-edit-unlock cycle kunt krijgen. Zie de manual over svn:needs-lock.

[H!GHGuY]

het gebeurt bij ons zowiezo dat meerdere mensen op een deel-project werken. dan kan edit-merge wel eens veel handiger zijn dan lock-edit-unlock...