[alg] Ervaringen met Source Control systemen.

[MBV]

Dit topic is afgesplitst van [alg] Slechtste programmeervoorbeelden deel 4

edit
Dit topic loopt een beetje uit op een vergelijking tussen de verschillende systemen, zoals VSS, SVN en GIT, maar lijkt zich vooral te concentreren op een vergelijking tussen de twee verschillende concepten. Als iemand een mooie TS in elkaar zet wil ik die best in dit topic zetten, stuur maar een mailtje.

Voorlopig 1 link met uitleg over distributed VCS:
http://betterexplained.co...sion-control-illustrated/


En hier mijn opmerking waar het mee begon:

---

Heerlijk hè, SVN een VCS ?

[ Voor 157% gewijzigd door MBV op 12-02-2009 18:31 . Reden: arme miertjes ]

[.oisyn]

SVN? Wat heeft dat ermee te maken?

[kenneth]

Dan kan je terug in de tijd om je eigen brainfarts weer te begrijpen

/wildegok

[.oisyn]

Dan had ie wel "source control" gezegd. 't Is niet alsof SVN het enige pakket is dat dat kan

[Erkens]

kenneth schreef op maandag 26 januari 2009 @ 11:50:
Dan kan je terug in de tijd om je eigen brainfarts weer te begrijpen

/wildegok

Niet als die functie uit een andere file kwam, dan kan je dat vrij moeilijk weer terug vinden

[kenneth]

.oisyn schreef op maandag 26 januari 2009 @ 11:51:
Dan had ie wel "source control" gezegd. 't Is niet alsof SVN het enige pakket is dat dat kan

Soort van pars pro toto

offtopic:
Net als bij Open Source, dan wordt er altijd voor het gemak maar van uitgegaan dat het over de GPL gaat

[MBV]

Ok, gefixed, ik bedoelde idd VCS

[kenneth]

Welkom op GoT, waar ieder woord op een zilveren schaaltje gewogen wordt
Wanneer we het eens zijn over wat zilver nu eigenlijk is en hoe groot het schaaltje moet zijn.

[.oisyn]

Nou ik dacht eigenlijk serieus dat MBV bedoelde dat er iets speciaals was aan SVN wat met de post van Face_-_LeSS te maken had

[MBV]

kenneth schreef op maandag 26 januari 2009 @ 12:35:
Wanneer we het eens zijn over wat zilver nu eigenlijk is en hoe groot het schaaltje moet zijn.

Dat maakt helemaal niet uit, zolang de schaaltjes maar in evenwicht zijn. Het gaat om de gewichtjes aan de andere kant

.oisyn schreef op maandag 26 januari 2009 @ 12:39:
Nou ik dacht eigenlijk serieus dat MBV bedoelde dat er iets speciaals was aan SVN wat met de post van Face_-_LeSS te maken had

SVN blame bedoelde ik, zit ook in CVS en GIT, maar ik dacht niet in Visual SourceSafe*

*) The real WTF is...

[.oisyn]

VSS is idd ruk, iedereen die dat gebruikt mag zich geen professionele developer noemen
Perforce heeft het trouwens ook

[HawVer]

.oisyn schreef op maandag 26 januari 2009 @ 14:07:
VSS is idd ruk, iedereen die dat gebruikt mag zich geen professionele developer noemen
Perforce heeft het trouwens ook

Want? Het is niet optimaal maar het werkt wel. Het is een verouderd pakket, maar de functionaliteit is verder nog prima.

[Amras]

HawVer schreef op zondag 08 februari 2009 @ 17:14:
[...]

Want? Het is niet optimaal maar het werkt wel. Het is een verouderd pakket, maar de functionaliteit is verder nog prima.

Mee eens. Op mijn huidige project (>3k functiepunten) gebruiken we ook Visual SourceSafe. Het is niet ideaal, maar het werkt wel. Ben wel benieuwd wat nieuwe versiebeheersystemen bieden, onder andere shelving lijkt me interessant (wordt niet door VSS ondersteund).

[!null]

Toen ik met SourceSafe heb gewerkt vond ik de duidelijkheid wel mooi, unlocken en locken. SVN biedt weer alle vrijheid, waarbij soms een klein beetje onduidelijkheid waardoor je moet mergen (wat natuurlijk niet erg is, als je een beetje van elkaar weet wat je doet).
SVN heeft wel wat meer voordelen, maar SourceSafe valt ook mee te werken idd. Ik ken eigenlijk geen andere pakketten.

Wat is shelving trouwens?

[!null]

Ah, shelving kan gewoon met SVN. Weet niet meer of het ook in Sourcesafe kon, er staat me bij dat dat niet kon.

Edit: Ik weet trouwens niet hoe duur die pakketten zijn, maar met SVN (dat overal op draait) vind ik het persoonlijk onzin om voor een versiebeheersysteem geld uit te geven.

[ Voor 44% gewijzigd door !null op 08-02-2009 23:14 ]

[.oisyn]

HawVer schreef op zondag 08 februari 2009 @ 17:14:
[...]

Want?

Onbetrouwbaar. Het werkt via network shares - iedere client heeft dus direct toegang tot de database files. Omdat iedere client de database direct bewerkt, gaat het fout zodra een client half werk verricht en de database in een bad state achterlaat (bijv. als de PC crasht oid). Natuurlijk heb je dat risico ook met de server zelf, maar bij VSS is dat risico bij X clients dus X keer zo groot. Verder raadt Microsoft zelf aan dat de db beter niet groter kan zijn dan 5 GB (wat peanuts is als je ook binaries incheckt), en ik heb verhalen gehoord over foute integrations tussen branches die je hele file histories verneuken.

Even een snelle search op "visual sourcesafe problems" leverde dit op: http://www.highprogrammer.com/alan/windev/sourcesafe.html en http://www.developsense.com/testing/VSSDefects.html

't Is misschien leuk voor de hobbyist die z'n eigen projectjes een beetje wilt managen, maar voor serieus werk zou ik echt enorm afraden.

GreenSky schreef op zondag 08 februari 2009 @ 18:23:
Toen ik met SourceSafe heb gewerkt vond ik de duidelijkheid wel mooi, unlocken en locken.

Da's niet uniek aan sourcesafe hoor . Wel meer pakketten houden er een checkout systeem op na, terwijl CVS en SVN idd op basis van commit werken. Het voordeel van het uit moeten checken is dat je precies kunt zien wie er allemaal met bepaalde files aan het werk zijn, het nadeel is dat zodra je even tijdelijk geen toegang hebt tot de server je feitelijk weinig kan (of je moet goed bijhouden welke files je gechanged hebt)

[ Voor 69% gewijzigd door .oisyn op 08-02-2009 23:52 ]

[PrisonerOfPain]

.oisyn schreef op zondag 08 februari 2009 @ 23:38:
[...]
Verder raadt Microsoft zelf aan dat de db beter niet groter kan zijn dan 5 GB (wat peanuts is als je ook binaries incheckt)

Ik had al geen goede indruk van VSS maar dat, gecombineerd met 't feit dat onze artists makkelijk een GB per week kunnen produceren denk ik niet dat ik dat product nog snel zal gebruiken...

[.oisyn]

De head revision van Tomb Raider: Underworld was om en nabij 350 GB. En dat is dus alleen de head revision he , ik heb geen exacte data over de grootte van de complete database. Dus nee, ook geen VSS voor ons . Wij gebruiken Perforce, wat trouwens ook vrij common is als source control software in de gamesindustrie.

[ Voor 16% gewijzigd door .oisyn op 09-02-2009 01:30 ]

[Snake]

.oisyn schreef op maandag 09 februari 2009 @ 01:29:
De head revision van Tomb Raider: Underworld was om en nabij 350 GB. En dat is dus alleen de head revision he , ik heb geen exacte data over de grootte van de complete database. Dus nee, ook geen VSS voor ons . Wij gebruiken Perforce, wat trouwens ook vrij common is als source control software in de gamesindustrie.

350GB aan textbestanden?

Wat is de head revision precies?

[NMe]

Snake schreef op maandag 09 februari 2009 @ 01:59:
[...]

350GB aan textbestanden?

.oisyn schreef op zondag 08 februari 2009 @ 23:38:
[...]

Verder raadt Microsoft zelf aan dat de db beter niet groter kan zijn dan 5 GB (wat peanuts is als je ook binaries incheckt),

[Snake]

NMe schreef op maandag 09 februari 2009 @ 02:15:
[...]


[...]

Okay. Maar wat zit in die binaries? Compiled source code?

[Verwijderd]

Artwork etc

[Amras]

.oisyn schreef op maandag 09 februari 2009 @ 01:29:
De head revision van Tomb Raider: Underworld was om en nabij 350 GB. En dat is dus alleen de head revision he , ik heb geen exacte data over de grootte van de complete database. Dus nee, ook geen VSS voor ons . Wij gebruiken Perforce, wat trouwens ook vrij common is als source control software in de gamesindustrie.

Dat is wel flink ja. Onze ontwikkelbranch is 7.3GB; binaries staan niet onder source control. Way beyond supported dus, al heeft dit nog niet tot serieuze issues geleid.

[MBV]

.oisyn schreef op zondag 08 februari 2009 @ 23:38:
[...]

Onbetrouwbaar. Het werkt via network shares - iedere client heeft dus direct toegang tot de database files. Omdat iedere client de database direct bewerkt, gaat het fout zodra een client half werk verricht en de database in een bad state achterlaat (bijv. als de PC crasht oid).

Inderdaad al regelmatig de melding gezien dat de administrator de integriteit moet checken. Ik zat dus al een poos te drammen om SVN.

Da's niet uniek aan sourcesafe hoor . Wel meer pakketten houden er een checkout systeem op na, terwijl CVS en SVN idd op basis van commit werken. Het voordeel van het uit moeten checken is dat je precies kunt zien wie er allemaal met bepaalde files aan het werk zijn, het nadeel is dat zodra je even tijdelijk geen toegang hebt tot de server je feitelijk weinig kan (of je moet goed bijhouden welke files je gechanged hebt)

Je kan het ook afdwingen op SVN, geloof ik. Standaard read-only checkouts instellen, en dan een lock aanvragen als je wilt wijzigen. Nadeel is dat je dan niet met meerdere mensen aan 1 bestand kan werken.

Oh ja, SVN is erg efficiënt: mijn (privé) repository-DB is 200MB groot, complete checkout is 500MB

[!null]

.oisyn schreef op zondag 08 februari 2009 @ 23:38:
Da's niet uniek aan sourcesafe hoor . Wel meer pakketten houden er een checkout systeem op na, terwijl CVS en SVN idd op basis van commit werken. Het voordeel van het uit moeten checken is dat je precies kunt zien wie er allemaal met bepaalde files aan het werk zijn, het nadeel is dat zodra je even tijdelijk geen toegang hebt tot de server je feitelijk weinig kan (of je moet goed bijhouden welke files je gechanged hebt)

Ja dat wist ik dat het niet uniek was. En je kan het idd ook afdwingen met SVN dacht ik, maar gaat aan de voordelen van SVN voorbij.
Van SVN vind ik ook dingen als Check for Modifications etc erg handig, zitten dat soort dingen ook in SourceSafe? (daar is het misschien ook minder nodig)

Ik heb toendertijd (is al wel weer 4 a 5 jaar terug, m'n eerste bijbaantje als programmeur ) ook gemerkt dat het behoorlijk onbetrouwbaar was, en dat collega's om een ander pakket zaten te zeuren. Welke weet ik niet meer.

[.oisyn]

Snake schreef op maandag 09 februari 2009 @ 01:59:
[...]

350GB aan textbestanden?

Textures, maya files, executables, libraries, en natuurlijk source code

Wat is de head revision precies?

De laatste versie

[MatHack]

GreenSky schreef op maandag 09 februari 2009 @ 10:16:
[...]


Ja dat wist ik dat het niet uniek was. En je kan het idd ook afdwingen met SVN dacht ik, maar gaat aan de voordelen van SVN voorbij.
Van SVN vind ik ook dingen als Check for Modifications etc erg handig, zitten dat soort dingen ook in SourceSafe? (daar is het misschien ook minder nodig)

Ik heb toendertijd (is al wel weer 4 a 5 jaar terug, m'n eerste bijbaantje als programmeur ) ook gemerkt dat het behoorlijk onbetrouwbaar was, en dat collega's om een ander pakket zaten te zeuren. Welke weet ik niet meer.

Dat soort dingen zitten wel in Team Foundation, maar niet in SourceSafe. Ik werk persoonlijk bij een Microsoft georiënteerd bedrijf, vandaar dat wij TFS gebruiken. Ik denk dat SVN net zo goed werkt. TFS wordt wel heel erg goed geïntegreerd in Visual Studio 2008, geen idee hoe dat zit met SVN & VS2008.

[roy-t]

MatHack schreef op maandag 09 februari 2009 @ 17:24:
[...]


Dat soort dingen zitten wel in Team Foundation, maar niet in SourceSafe. Ik werk persoonlijk bij een Microsoft georiënteerd bedrijf, vandaar dat wij TFS gebruiken. Ik denk dat SVN net zo goed werkt. TFS wordt wel heel erg goed geïntegreerd in Visual Studio 2008, geen idee hoe dat zit met SVN & VS2008.

SVN en VS2008 is niet geinteregeerd, maar je hebt wel TortoiseSVN wat opzich wel aardig is, er is ook een betaalde plugin voor VS2008 die integreerd met SVN, zelf niet gebruikt, maar heb gehoord dat deze niet altijd even stabiel en handig is.

[!null]

TortoiseSVN biedt genoeg mogelijkheden, en door de werkwijze van SVN vind ik integratie ook niet echt nodig eigenlijk. Maar misschien ben ik daar de enige in.

[Verwijderd]

Voor visual studio heb je VisualSVN, wat opzich wel goed werkt naar mijn ervaring. Maar inderdaad wel betaalde software helaas.

Momenteel gebruik ik echter Eclipse als IDE. Hier zijn ook voldoende SVN plugins voor.

Uiteindelijk merk ik toch wel dat ik de voorkeur geef aan een plugin in de IDE dan gewoon Tortoise for Windows te gebruiken...

O.a. om in zo min mogelijk stappen een up-to-date versie te hebben, niet eerst via het OS en dan in de IDE weer refreshen bijvoorbeeld.
Verder is het ook makkelijk om te zien wat je in welke sourcefiles hebt aangepast tov de huidige revisie dmv kleurcodes.

[ Voor 27% gewijzigd door Verwijderd op 09-02-2009 21:10 ]

[MBV]

Mwoah, integratie is best handig. Ik werk zelf veel met eclipse, en de integratie daarin (diffs met syntax highlighting, inklapbare code, structuurwijzigingen, simpelweg niet een ander window hoeven openen en daarin de goede directory, automatische uitsluiting van gegenereerde bestanden) stel ik toch heel erg op prijs.

Maar is dit niet een beetje offtopic? SVN is geen slecht voorbeeld namelijk

[user109731]

Een open-source SVN plugin voor VS is AnkhSVN. Ik heb het zelf echter nooit gebruikt, weet dus niet hoe goed het is

Netbeans heeft ook prima SVN integratie..

[ Voor 28% gewijzigd door user109731 op 09-02-2009 22:59 ]

[Gorion3]

JanDM schreef op maandag 09 februari 2009 @ 22:55:
Een open-source SVN plugin voor VS is AnkhSVN. Ik heb het zelf echter nooit gebruikt, weet dus niet hoe goed het is

Netbeans heeft ook prima SVN integratie..

Ik gebruik het al behoorlijk lang (ongeveer een jaar) en het werkt erg fijn Soms wil het nog wel crashen, bijvoorbeeld als een merge niet helemaal goed is gelopen en dan is het niet echt fijn, maar om eerlijk te zijn was het vandaag voor de eerste keer dat dat voorkwam .

Een relatief klein spel als Hydro Tilt is uiteindelijk rond de 4GB geworden, let wel op, wij hadden geen binaries gecommit, dus alleen source code en art (muziek, textures, etc). Wij gebruikte SVN i.c.m. SmartSVN op de mac (welke trouwens behoorlijk traag is, maarja het is ook gemaakt in java, wat niet echt wil helpen natuurlijk).

[roy-t]

Gorion3 schreef op maandag 09 februari 2009 @ 23:04:
[...]


Ik gebruik het al behoorlijk lang (ongeveer een jaar) en het werkt erg fijn Soms wil het nog wel crashen, bijvoorbeeld als een merge niet helemaal goed is gelopen en dan is het niet echt fijn, maar om eerlijk te zijn was het vandaag voor de eerste keer dat dat voorkwam .

Een relatief klein spel als Hydro Tilt is uiteindelijk rond de 4GB geworden, let wel op, wij hadden geen binaries gecommit, dus alleen source code en art (muziek, textures, etc). Wij gebruikte SVN i.c.m. SmartSVN op de mac (welke trouwens behoorlijk traag is, maarja het is ook gemaakt in java, wat niet echt wil helpen natuurlijk).

Klein spel 4GB source-code? Damn, sorry maar dat noem ik niet meer klein. Ik dacht eerst nog even dat binaries vaak kleiner zijn dan source-code (compressie) maar SVN gebruikt ook compressie dus dat zou niet al te veel uit mogen maken, waar kwam je uiteindelijk op uit op DVD met binaries?

[Olaf van der Spek]

roy-t schreef op maandag 09 februari 2009 @ 23:18:
Klein spel 4GB source-code?

En art...

[.oisyn]

dus alleen source code en art (muziek, textures, etc)

Overigens heten dat ook binaries.

[roy-t]

Olaf van der Spek schreef op dinsdag 10 februari 2009 @ 00:10:
[...]

En art...

Pardon die had ik er in gedachte ook bij gezet, maar dat was even onduidelijk. Maar toch een klein spel 4GB. Natuurlijk zitten er meerdere versies in de repo, maar vooral een groot ouder spel (ala UT'99) enzo kwamen niet over de 600MB.

[.oisyn]

Je vergeet even intermediate en source files. Een game heeft uiteindelijk alleen maar de binaries die hij direct inlaadt. Maar in je source control staan ook bijv. de textures in PSD formaat, muziek en geluidseffecten als .wav, de max/maya modellen, en eventueel tussenliggende stappen zoals een geexporteerd model in een handig formaat zodat de tools er makkelijk mee kunnen werken. Er is een behoorlijke shitload aan data duplicatie, en bovendien ga je de bron files niet lossy compressed opslaan.

Zoals ik al zei, Tomb Raider: Underworld is 350 GB. Dat past echt niet op 1 DVD, maar toch shipt de game zelf wel op een DVD

[ Voor 14% gewijzigd door .oisyn op 10-02-2009 10:41 ]

[Zoijar]

Als je aan far cry 2 denkt en dat ook allemaal inchecked zit je er zo...

We ended up making it back in one piece after two intense weeks and brought back over 40 hours of HD footage, over 8 Gigs of reference pictures and a truly priceless experience.

[roy-t]

Damn ik had gewoon geen idee dat programma's zo snel zouden groeien in een repo. Ik gebruik zelf een lokaal gehoste repo voor sommige projectjes/techdemo's zodat ik fouten kan herstellen, maar de grootste daarvan is slechts 10MB (nu zit daar niet bijster veel art in enzo ).

Hmm dit opent mijn ogen zeker!

[djc]

Hmm, ik gebruik nu al weer ruim een jaar Mercurial. Werkt echt een stuk fijner dan SVN; veel makkelijker om een nieuw repo te beginnen, en het is veeeel sneller. Plus dat er een fijne web interface inzit, die je met hg serve tevoorschijn kan toveren, en omdat het in Python geschreven is en een goed plugin-model heeft zijn er een aantal zeer behulpzame extensies (onder andere hgsubversion).

Ben er een beetje verbaasd over dat hier nog bijna niet met Distributed Version Control Systems gewerkt lijkt te worden (behalve Perforce); wat mij betreft is SVN al behoorlijk last-generation (om maar niet te spreken van de MS-producten, waar ik niets dan slechts over gehoord heb).

[Erkens]

djc schreef op dinsdag 10 februari 2009 @ 13:43:
Hmm, ik gebruik nu al weer ruim een jaar Mercurial. Werkt echt een stuk fijner dan SVN; veel makkelijker om een nieuw repo te beginnen

Ik ken Mercurial (nog) niet, maar veel makkelijker dan "svnadmin create REPOS_PATH" kan het toch volgens mij niet?

[HawVer]

.oisyn schreef op zondag 08 februari 2009 @ 23:38:
[...]

Onbetrouwbaar. Het werkt via network shares - iedere client heeft dus direct toegang tot de database files. Omdat iedere client de database direct bewerkt, gaat het fout zodra een client half werk verricht en de database in een bad state achterlaat (bijv. als de PC crasht oid). Natuurlijk heb je dat risico ook met de server zelf, maar bij VSS is dat risico bij X clients dus X keer zo groot.

Wij hebben zelf geen negatieve ervaringen met sourcesafe. Het komt wel eens voor dat een pc vastloopt tijdens het in- en uitchecken. De praktijk is dat de bestanden dan maar deels ingechecked zijn. Uiteindelijk krijg je dan twee revisies in de sourcesafe database. Of je moet de revisie waar het fout gaat verwijderen. Daarnaast heb je een analyze utility die de database kan controleren op mogelijke problemen. Ik heb die tool zelf nooit nodig gehad.

Verder raadt Microsoft zelf aan dat de db beter niet groter kan zijn dan 5 GB (wat peanuts is als je ook binaries incheckt),

Ik zou Visual Sourcesafe niet snel gebruiken om binaries in te checken. Wij gebruiken sourcesafe alleen voor het in- en uitchecken van broncode. De source is om en nabij de 2,1 Gb, gezien het aantal jaren werk en de grootte van de huidige database maak ik me geen zorgen om die 5 Gb limiet. Het grootste probleem van sourcesafe is dat er nul komma niks support meer op zit. Het product is echt uitgerangeerd. Wij orienteren ons nu op Team Foundation Server.

Ik kan me voorstellen dat in de gameindustrie geen optie is om geen binaries in te checken.

en ik heb verhalen gehoord over foute integrations tussen branches die je hele file histories verneuken.

Het branchen is inderdaad ruk. Ik heb die functionaliteit nooit gebruikt omdat het zo ondoorzichtig is. Als je niet 100% zekerheid hebt over wat je doet kun je in sourcesafe zo ineens je complete revisie historie kwijt zijn.

Even een snelle search op "visual sourcesafe problems" leverde dit op: http://www.highprogrammer.com/alan/windev/sourcesafe.html en http://www.developsense.com/testing/VSSDefects.html

Ik vind dat niet helemaal relevante links. Er zijn een aantal problemen met sourcesafe die ik wel herken, maar er zijn ook een aantal punten die gebaseerd zijn op persoonlijke voorkeur. De integratie met visual studio is inderdaad bijzonder instabiel.

't Is misschien leuk voor de hobbyist die z'n eigen projectjes een beetje wilt managen, maar voor serieus werk zou ik echt enorm afraden.

Flauw om over -hobbyist- te beginnen. Voor nieuwe projecten raad ik het gebruik van sourcesafe ook af. Voor bestaande trajecten zou ik niet op stel en sprong overstappen. Sourcesafe is een pakket dat sterk aan het verouderen is zowel op technisch als op functioneel niveau.

Da's niet uniek aan sourcesafe hoor . Wel meer pakketten houden er een checkout systeem op na, terwijl CVS en SVN idd op basis van commit werken. Het voordeel van het uit moeten checken is dat je precies kunt zien wie er allemaal met bepaalde files aan het werk zijn, het nadeel is dat zodra je even tijdelijk geen toegang hebt tot de server je feitelijk weinig kan (of je moet goed bijhouden welke files je gechanged hebt)

Met sourcesafe kun je de laatste versie binnenhengelen naar je lokale pc. Mocht sourcesafe niet bereikbaar zijn dan kun je toch je lokale versie aanpassen. Je verwijderd de read only flag en past je bestanden aan. Op een later tijdstip kun je sourcesafe starten en dmv diff algorithme in sourcesafe kun je snel zien welke bestanden op je lokale pc zijn gewijzigd tov de server versie.

Er zijn meer voordelen aan het checkout systeem. Je lokale repository raakt niet snel corrupt. Dat is een probleem waar ik bij opensource projecten nogal vaak tegen aanliep. Als je te lang je werk niet incheckt bij svn moet je eerst de laatste versie ophalen en daarna je lokale conflicten oplossen, wat in SVN een ware frustatie is.

[kenneth]

djc schreef op dinsdag 10 februari 2009 @ 13:43:
Hmm, ik gebruik nu al weer ruim een jaar Mercurial. Werkt echt een stuk fijner dan SVN; veel makkelijker om een nieuw repo te beginnen, en het is veeeel sneller. Plus dat er een fijne web interface inzit, die je met hg serve tevoorschijn kan toveren, en omdat het in Python geschreven is en een goed plugin-model heeft zijn er een aantal zeer behulpzame extensies (onder andere hgsubversion).

Ben er een beetje verbaasd over dat hier nog bijna niet met Distributed Version Control Systems gewerkt lijkt te worden (behalve Perforce); wat mij betreft is SVN al behoorlijk last-generation (om maar niet te spreken van de MS-producten, waar ik niets dan slechts over gehoord heb).

Wat voor grote commits doe jij dat het 'veeeeel sneller' is? Het zal wel aan mij liggen, maar dan heb je het over secondes of minuten ofzo? Ik heb niet het idee dat svn supersnel is, maar ik doe ook geen vijftig checkouts/commits/diffs per uur dat snelheid zo een ontzettend zwaarwegend argument zou zijn.

En waarom DVCS niet populair is? Omdat er geen behoefte aan is

HawVer schreef op dinsdag 10 februari 2009 @ 13:48:
Er zijn meer voordelen aan het checkout systeem. Je lokale repository raakt niet snel corrupt. Dat is een probleem waar ik bij opensource projecten nogal vaak tegen aanliep. Als je te lang je werk niet incheckt bij svn moet je eerst de laatste versie ophalen en daarna je lokale conflicten oplossen, wat in SVN een ware frustatie is.

Tsja, maar VCS is geen excuus voor een gebrek aan communicatie. Een VCS constateert alleen maar conflicten, die veroorzaakt ze niet.

[ Voor 70% gewijzigd door kenneth op 10-02-2009 13:53 ]

[HawVer]

kenneth schreef op dinsdag 10 februari 2009 @ 13:50:
[...]
Tsja, maar VCS is geen excuus voor een gebrek aan communicatie. Een VCS constateert alleen maar conflicten, die veroorzaakt ze niet.

Klopt, communicatie blijft altijd belangrijk. Het constateren van het probleem is niet het probleem. Met een checkout principe voorkom je al dat je conflicten krijgt. Mijn persoonlijke ervaring is dat het oplossen van het conflict in svn bijvoorbeeld nogal wat werk kost.

[MBV]

Zoals al eerder is verteld, kan je in SVN ook locks afdwingen, en daar een checkout-systeem mee krijgen. Daar zitten weer zoveel nadelen aan voor opensource projecten (veel contributors die weinig doen, dus een lange doorlooptijd hebben) dat weinig mensen dat gebruiken.

[kenneth]

HawVer schreef op dinsdag 10 februari 2009 @ 14:03:
[...]

Klopt, communicatie blijft altijd belangrijk. Het constateren van het probleem is niet het probleem. Met een checkout principe voorkom je al dat je conflicten krijgt. Mijn persoonlijke ervaring is dat het oplossen van het conflict in svn bijvoorbeeld nogal wat werk kost.

En met een checkout-principe krijg je weer dat mensen moeten duimendraaien. Kortom, het hangt een beetje van de aard van het project af

[Olaf van der Spek]

HawVer schreef op dinsdag 10 februari 2009 @ 14:03:
Klopt, communicatie blijft altijd belangrijk. Het constateren van het probleem is niet het probleem. Met een checkout principe voorkom je al dat je conflicten krijgt. Mijn persoonlijke ervaring is dat het oplossen van het conflict in svn bijvoorbeeld nogal wat werk kost.

Heeft svn daar niet svn lock voor?

[.oisyn]

kenneth schreef op dinsdag 10 februari 2009 @ 14:12:
[...]

En met een checkout-principe krijg je weer dat mensen moeten duimendraaien. Kortom, het hangt een beetje van de aard van het project af

Da's ook onzin. Een checkout systeem verhindert niet dat anderen 'm niet ook mogen uitchecken. Daar heb je locks voor (sterker nog, met Perforce kun je nog steeds gelockte files uitchecken, alleen niet inchecken). Het systeem zorgt er wel voor dat je weet dat anderen óók met die file bezig zijn, en dan kun je daarover communiceren.

[ Voor 8% gewijzigd door .oisyn op 10-02-2009 14:21 ]

[Mr_Light]

djc schreef op dinsdag 10 februari 2009 @ 13:43:
Hmm, ik gebruik nu al weer ruim een jaar Mercurial. Werkt echt een stuk fijner dan SVN; veel makkelijker om een nieuw repo te beginnen, en het is veeeel sneller. Plus dat er een fijne web interface inzit, die je met hg serve tevoorschijn kan toveren, en omdat het in Python geschreven is en een goed plugin-model heeft zijn er een aantal zeer behulpzame extensies (onder andere hgsubversion).

Ben er een beetje verbaasd over dat hier nog bijna niet met Distributed Version Control Systems gewerkt lijkt te worden (behalve Perforce); wat mij betreft is SVN al behoorlijk last-generation (om maar niet te spreken van de MS-producten, waar ik niets dan slechts over gehoord heb).

GIT

Google Tech Talk: Linus Torvalds on git

Tool supportintegratie mag alleen nog wel beter.

[ Voor 6% gewijzigd door Mr_Light op 10-02-2009 17:06 ]

[Nick_S]

.oisyn schreef op dinsdag 10 februari 2009 @ 14:20:
[...]


Da's ook onzin. Een checkout systeem verhindert niet dat anderen 'm niet ook mogen uitchecken. Daar heb je locks voor (sterker nog, met Perforce kun je nog steeds gelockte files uitchecken, alleen niet inchecken). Het systeem zorgt er wel voor dat je weet dat anderen óók met die file bezig zijn, en dan kun je daarover communiceren.

Met een "checkout systeem" wordt hier waarschijnlijk "Lock-Modify-Unlock" bedoeld, itt. "Copy-Modify-Merge" zoals gebruikt wordt door oa. SVN en CVS.

[.oisyn]

Dat maak jij ervan, en wellicht ook de poster op wie ik reageerde. Maar dat betekent niet dat dat zo hoeft te zijn, en ik leg juist uit van niet .

Er werd genoemd dat een van de voordelen van "een" checkout systeem (even in het midden gelaten hoe dat dan geïmplementeerd is) is dat je kunt zien dat anderen ook aan die bestanden werken. Daarop kwam het tegenargument dat anderen dan niets meer met die file kunnen doen. Ik zeg dat dat onzin is. Dat is helemaal niet het nadeel van een checkout systeem - wellicht wel een nadeel van een specifieke (en idd onhandige) implementatie van een dergelijk systeem, maar niet inherent aan het uit moeten checken zelf.

Natuurlijk kun je met pakketten als TF en Perforce ook gewoon alles uitchecken, en als je iets submit ook uitgecheckt laten. Heb je in de regel exact hetzelfde systeem als CVS en SVN, dus je bent nog steeds van programmeurs afhankelijk dat ze alleen die files uitchecken waar ze changes aan maken. Maar daar zorgt fatsoenlijke integration weer voor.

[ Voor 86% gewijzigd door .oisyn op 10-02-2009 16:14 ]

[kenneth]

Dat wist ik dus niet

Alleen maar praktijkervaring met svn, voor de rest heb ik alleen her en der wat klokken horen luiden

[Woy]

HawVer schreef op dinsdag 10 februari 2009 @ 13:48:
Het branchen is inderdaad ruk. Ik heb die functionaliteit nooit gebruikt omdat het zo ondoorzichtig is. Als je niet 100% zekerheid hebt over wat je doet kun je in sourcesafe zo ineens je complete revisie historie kwijt zijn.

Maar dat maakt het meteen een nogal onbetrouwbaar systeem. Juist bij een VCS wil je altijd terug kunnen naar een oude versie, als je dan op allerlei maniere je historie kwijt kan raken vind ik dat toch wel een ernstige fout.

Hier is in het verleden ook altijd Visual SourceSafe gebruikt, maar gelukkig zijn we nu wel over naar SVN. Alleen onze oude projecten staan nog in sourcesafe, maar die worden langzaamaan overgezet naar SVN als er nog wijzigingen in gedaan worden.

[Verwijderd]

Ik heb niet zoveel ervaring met source control, maar ik heb op de universiteit Subversion gebruikt, en persoonlijk Git. Bij Git heb ik echt het idee dat het de 'juiste' benadering is. Het werkt lokaal op jouw pc, houdt jouw persoonlijke wijzigingen per commit bij, en die historie gaat niet verloren als je later merged met de main repository op de server.

Bij Subversion moet je altijd verbonden zijn met de server, en doet iedereen van die gigantische commits waardoor je constant conflicten krijgt.

Oja, ik gebruik het nog niet echt, maar je kan met Git voor elke mini-feature een branch maken, en die later weer mergen met je master branch. Het is dan een soort tree-based undo feature.

[ Voor 16% gewijzigd door Verwijderd op 10-02-2009 17:28 ]

[Verwijderd]

Verwijderd schreef op dinsdag 10 februari 2009 @ 17:26:
Bij Subversion moet je altijd verbonden zijn met de server, en doet iedereen van die gigantische commits waardoor je constant conflicten krijgt.

Altijd is overdreven, in de tijd tussen een checkout/update en een commit hoeft er natuurlijk geen verbinding te zijn.

Waar je met een wat groter team misschien wel last van hebt is wanneer mensen tegelijkertijd veranderingen aan hetzelfde stuk gaan committen ja, maar daarvoor zijn de locks ook uitgevonden .

[ Voor 20% gewijzigd door Verwijderd op 10-02-2009 17:29 ]

[Erkens]

Verwijderd schreef op dinsdag 10 februari 2009 @ 17:26:
Bij Subversion moet je altijd verbonden zijn met de server, en doet iedereen van die gigantische commits waardoor je constant conflicten krijgt.

Met SVN (Subversion) werk je juist lokaal in je eigen checkout, daarna kan je dat comitten, en daarvoor moet je natuurlijk wel online zijn, maar dat is bij al die systemen

Verder krijg je met elk systeem vroeg of laat wel te maken met conflicten. En of iemand altijd "gigantische commits" doet ligt natuurlijk aan de manier waarop je het gebruikt.

Zeker met de 1.5 versie van SVN houdt het systeem bij wanneer en met welke branches je hebt gemerged zodat je daar zelf niet meer op hoeft te letten.

[MBV]

Misschien is GIT ook wel veel beter. Er is een reden dat Linus GIT (een commercieel programma) voor de kernel wilde gebruiken. Maar de keren dat ik het ergens voor nodig had snapte ik echt niet meer waar ik mee bezig was, juist doordat het zoveel kan. De grote kracht van SVN is juist dat het veel beperkter is dan CVS, en daardoor eenvoudiger te begrijpen.
En dat iedereen van die mega-commits doet met SVN, tja, dat kan met GIT nog steeds toch?

[.oisyn]

MBV schreef op dinsdag 10 februari 2009 @ 17:31:
Er is een reden dat Linus GIT (een commercieel programma) voor de kernel wilde gebruiken

Duh, hij heeft het zelf gemaakt . En 't is trouwens gratis. Ben je niet in de war met BitKeeper, wat eerder voor de kernel is gebruikt en waar Git op gebaseerd is?

Ik moet zeggen dat ik er ook wel wat in zie. 't Komt toch wel eens voor dat ik iets niet in de main branch wil submitten maar toch even met mijn directe collega's wil sharen. Even een branch maken is er niet echt bij - voornamelijk ook omdat branches in Perforce geen views op de standaard directory structuur zijn maar echte aparte directories. Die kun je dan wel weer op de goede plek op je schijf mappen maar erg handig is het niet. Bovendien kun je je huidige change niet branchen - dan moet je eerst branchen, die nieuwe branch uitchecken en dan je changes er overheen kopiëren.

Gelukkig hebben we een intern checkpoint tooltje die een change kan backuppen, dan kan iemand anders die restoren waarbij de tool automatisch de juiste revisies van de files uitcheckt en dan de changes er overheen zet.

[ Voor 75% gewijzigd door .oisyn op 10-02-2009 17:50 ]

[MBV]

.oisyn schreef op dinsdag 10 februari 2009 @ 17:43:
[...]

Duh, hij heeft het zelf gemaakt . En 't is trouwens gratis. Ben je niet in de war met BitKeeper, wat eerder voor de kernel is gebruikt en waar Git op gebaseerd is?

Dan heb je duidelijk niet opgelet: Linus had een contract met BitKeeper, dat het gratis gebruikt mocht worden als er geen GPL implementatie van kwam. Die kwam toch, en daar was linus erg boos om Ik was alleen de naam van bitkeeper vergeten, dacht eigenlijk dat GIT de naam van het protocol was.

Ik moet zeggen dat ik er ook wel wat in zie. 't Komt toch wel eens voor dat ik iets niet in de main branch wil submitten maar toch even met mijn directe collega's wil sharen. [knip]

Ik zou even de syntax na moeten kijken, maar in SVN is een branch aanmaken ook in 1 minuut gedaan. Mergen met de main branch is dan wel weer wat lastig.

[LauPro]

Mja GIT is voor kernel developing ideaal. Je hebt daarbij een grote sourcetree waarmij de deelnemers een groot stuk vaak onderhanden nemen. De branching zoals dat in SVN zit is dan niet meer werkbaar omdat het onnavolgbaar is wat er precies allemaal wordt gemerged.

De decentraliteit van GIT vind ik niet altijd een voordeel. Zo wil je in commerciële softwareontwikkeling meestal de wijzingen centraal kunnen volgen en niet indirect. Het balang bij GIT ligt dan ook bij de auteur ipv het gemeenschappelijke doel. Als mensen het niet eens worden met een kernelontwikkeling kan je met GIT zo een nieuwe branch gaan starten, dat kan natuurlijk nooit de bedoeling zijn binnen een bedrijf.

[.oisyn]

MBV schreef op dinsdag 10 februari 2009 @ 17:58:
[...]

Dan heb je duidelijk niet opgelet: Linus had een contract met BitKeeper, dat het gratis gebruikt mocht worden als er geen GPL implementatie van kwam. Die kwam toch, en daar was linus erg boos om Ik was alleen de naam van bitkeeper vergeten, dacht eigenlijk dat GIT de naam van het protocol was.

Dude, lees mijn post nog een keer, want er staat niets in wat tegen wat jij nu zegt in gaat .

Jij zegt: Linus wil git, een commercieel pakket. Ik zeg: duh, Linus heeft git gemaakt, en git is geen commercieel pakket. Ergo: ben je niet in de war met BitKeeper, wat idd eerder voor Linux is gebruikt, een commercieel pakket is, en waar git op is gebaseerd (daarmee bedoel ik: de ideeën van een decentraal opslagsysteem e.d. van BitKeeper zijn ook in Git verwerkt).

Dat ze over zijn gegaan op Git omdat BitKeeper ineens niet meer gratis was wist ik, maar dat ontkende ik ook helemaal niet in die post. Ik noemde het gewoon niet . Overigens is het niet zo dat er een GPL implementatie van BitKeeper kwam, alleen kwam er een gratis tool die file history en metadata uit de BitKeeper database kon halen - een feature die BitKeepeer wel had maar die je alleen mocht gebruiken als je voor het pakket betaalde.

[ Voor 47% gewijzigd door .oisyn op 10-02-2009 18:27 ]

[MBV]

"Duh, hij heeft het zelf gemaakt" zei je toch? Linus wilde dat juist tegenhouden, tenminste, dat heb ik ervan onthouden, en dat gaat lijnrecht tegen het verhaal in. En kennelijk was ik in de war tussen die tool en het complete pakket.

[Soultaker]

Erkens schreef op dinsdag 10 februari 2009 @ 17:30:
Met SVN (Subversion) werk je juist lokaal in je eigen checkout, daarna kan je dat comitten, en daarvoor moet je natuurlijk wel online zijn, maar dat is bij al die systemen

Volgens mij heb je alleen je huidige checkout lokaal. Om een log op te vragen van recente wijzigingen of een bestand te vergelijken met een oude revisie heb je weer wel de server nodig Behoorlijk vervelend als de Subversion server traag is. Met Git (of elk andere DVCS) kun je dat allemaal lokaal doen.

Verder hoef je voor het committen van lokale wijzigingen met Git juist níet online te zijn. Dat is fijn als je wat hebt zitten prutsen, nog niet klaar bent om je wijzigingen in de gedeelde repository op te nemen, maar wel tussentijds je veranderingen wil committen zodat je er later op terug kunt vallen. Met subversion moet je toch echt je veranderingen in de server comitten (desnoods in een aparte branch).

[Soultaker]

MBV schreef op dinsdag 10 februari 2009 @ 18:30:
"Duh, hij heeft het zelf gemaakt" zei je toch? Linus wilde dat juist tegenhouden, tenminste, dat heb ik ervan onthouden, en dat gaat lijnrecht tegen het verhaal in. En kennelijk was ik in de war tussen die tool en het complete pakket.

Git is niet die BitKeeper tool hoor. Zoals .oisyn zegt werd Git geschreven door Linus Torvalds omdat 'ie wat anders dan BitKeeper nodig had voor het Linux kernel project. Git is verder niet direct gebaseerd op BitKeeper (behalve dat 'ie er hier en daar wel door zal zijn geïnspireerd).

Dus ja, Linus Torvalds is voorstander van Git voor source code management, en ja, dat is nogal wiedes aangezien die die tool voor gebruik in zijn eigen kernel project ontwikkeld heeft. Daarvóór was Torvalds ook een voorstander van BitKeeper, maar v.z.i.w. was dat vooral gebaseerd op pragmatische redenen (hij vond het beter dan CVS, wat toen zo'n beetje het enige beproefde open-source VCS was).

[Verwijderd]

LauPro schreef op dinsdag 10 februari 2009 @ 18:03:
Mja GIT is voor kernel developing ideaal. Je hebt daarbij een grote sourcetree waarmij de deelnemers een groot stuk vaak onderhanden nemen. De branching zoals dat in SVN zit is dan niet meer werkbaar omdat het onnavolgbaar is wat er precies allemaal wordt gemerged.

De decentraliteit van GIT vind ik niet altijd een voordeel. Zo wil je in commerciële softwareontwikkeling meestal de wijzingen centraal kunnen volgen en niet indirect. Het balang bij GIT ligt dan ook bij de auteur ipv het gemeenschappelijke doel. Als mensen het niet eens worden met een kernelontwikkeling kan je met GIT zo een nieuwe branch gaan starten, dat kan natuurlijk nooit de bedoeling zijn binnen een bedrijf.

Volgens mij is Git ook prima centraal te gebruiken. Wine gebruikt Git als versie-beheer, maar normaal gesproken komen de veranderingen gewoon binnen per mail in de vorm van patches. Dat gebeurt bij Linux overigens ook veel.

Maar bij Git heb je dan het voordeel dat je lokaal ook op micro-niveau versie-beheer hebt. Bij centrale systemen kan je alleen maar globaal bezig zijn. Elke commit moet dan ook echt commit-waardig zijn, anders zit je anderen in de weg.

Ik heb als student geen ervaring met alle lapmiddelen die worden gebruikt in productie, zoals locking en naming conventions voor branches. Die zullen de problemen wel verzachten. Maar zoals ik eerder zei: volgens mij is Git (nouja, decentrale systemen dus) de enige benadering die echt 'juist' aanvoelt.

[DiedX]

We maken op "de zaak" gebruik van Mercurial. Onze hoofdprogrammeur raadde het aan, er waren aanzienlijke verschillen met SVN/CVS, en ook met git. Hij doet pushen (lees: commits) via GPG-geencrypte email vanuit Frankrijk.

Zelf heb ik het luchtig gehouden met mijn eigen SVN-Repo voor school. Binairy blobs (word ) for the win!

[MBV]

Soultaker schreef op dinsdag 10 februari 2009 @ 18:30:
[...]

Volgens mij heb je alleen je huidige checkout lokaal. Om een log op te vragen van recente wijzigingen of een bestand te vergelijken met een oude revisie heb je weer wel de server nodig Behoorlijk vervelend als de Subversion server traag is. Met Git (of elk andere DVCS) kun je dat allemaal lokaal doen.

Bijna goed: met base kan je vergelijken zonder netwerktoegang. Ik kan het nu niet voor je testen, maar in het mapje .svn staat de versie van het bestand die je het laatste hebt uitgecheckt.

En excuses voor mijn beperkte kennis van GIT/BitKeeper en toch de wijsneus willen uithangen

[ Voor 7% gewijzigd door MBV op 10-02-2009 19:10 ]

[.oisyn]

Soultaker schreef op dinsdag 10 februari 2009 @ 18:39:
Git is verder niet direct gebaseerd op BitKeeper (behalve dat 'ie er hier en daar wel door zal zijn geïnspireerd).

Ah ja, geïnspireerd is idd een beter woord en wat ik bedoelde

LauPro schreef op dinsdag 10 februari 2009 @ 18:03:
De decentraliteit van GIT vind ik niet altijd een voordeel. Zo wil je in commerciële softwareontwikkeling meestal de wijzingen centraal kunnen volgen en niet indirect. Het balang bij GIT ligt dan ook bij de auteur ipv het gemeenschappelijke doel. Als mensen het niet eens worden met een kernelontwikkeling kan je met GIT zo een nieuwe branch gaan starten, dat kan natuurlijk nooit de bedoeling zijn binnen een bedrijf.

Het is natuurlijk maar hoe je er gebruik van maakt. Het is niet inherent aan GIT dat iedereen aan z'n eigen branches werkt. Je kunt ook "afdwingen" (als in, company policy) dat je changes direct doormerged naar de main branch. De optie om tussentijds changes te submitten zonder de main branch te vervuilen of af en toe iets te delen met collega's is wel iets dat ik mis in Perforce.

[Mr_Light]

in die google tech talk daar word echt alles kraak helder uitgelegd. meeste van bovenstaande vragen worden beantwoord.

[Morax]

Ik heb ook dat filmpje van de Google Tech Talk bekeken, en op zich vind ik de aanpak van GIT wel mooi, maar er is 1 ding waar ik me zorgen over maak (Wat meer een algemeen iets is van de distributed aanpak):

Ik ben in zo'n geval bang dat je een wirwar van branches gaat krijgen die zo chaotisch is dat er geen kaas van te maken is. Pietje heeft namelijk de bugfix van Klaas. Klaas heeft echter niet de veranderingen van Pietje, maar wel die van Peter. Peter heeft op zijn beurt weer de nieuwe feature van Mark gekregen, en heeft die nieuwe feature gelijk meegegeven aan Klaas enzovoorts enzovoorts. Uiteindelijk weet niemand meer welke wijzigingen hij wel en niet heeft gehad en krijg je een wirwar van branches die niet te overzien is.

Op zich ben ik wel voor het gebruik van GIT, maar bovenstaand probleem houdt mij toch nog wel tegen moet ik zeggen.

[MBV]

Inderdaad, daar liep ik ook tegenaan toen ik een fix in de ATi-driver wilde overzetten naar mijn type kaart (voor automatisch terugklokken bij 2d-gebruik). Er was een GIT-branch van, waarin die fix was gedaan, maar ik had geen idee hoe ik het verschil tussen die branch en het moment van afsplitsing moest bekijken...

[Mr_Light]

Morax schreef op woensdag 11 februari 2009 @ 10:29:
Uiteindelijk weet niemand meer welke wijzigingen hij wel en niet heeft gehad en krijg je een wirwar van branches die niet te overzien is.

Goede kans dat je niet eens alle wijzigingen wilt

pullen van klaas en pullen van pietje

Mocht je eerst van klaas pullen en dan van pietje welke conflicten oplevert even aan Pietje vragen of hij eerst van klaas pulled en dan pull jij weer van hem.

In een gecontroleerde/corparate omgeving is er toch al iemand aangewezen die verantwoordelijk is voor een bepaald product. als iedereen gewoon vraagt aan hem om te pullen en als hij conflicten tegen komt etc.

Lijkt me een van die problemen die op papier erg lijkt maar in de praktijk niet meer voor komt. Daarnaast heb je in svn ook branches - alleen met git gaat het over content en niet over files dus merged het 3 keer makkelijker. Daarnaast word nog steeds aan iemand een taak toegewezen, dus weet je dat die branch bestaat er waar je hem kan vinden. - om te herhalen waar we het hier over hadden voordat we het over GIT hadden:

Tsja, maar VCS is geen excuus voor een gebrek aan communicatie.

[djc]

Erkens schreef op dinsdag 10 februari 2009 @ 13:47:
Ik ken Mercurial (nog) niet, maar veel makkelijker dan "svnadmin create REPOS_PATH" kan het toch volgens mij niet?

Alleen al het feit dat je er een ander commando voor nodig hebt vond ik irritant. En dan moet je nog een aparte checkout maken (bij hg init heb je meteen al een working directory). Plus dat Mercurial veel sneller is.

Verder is git geen afkorting ofzo, het wordt dus niet als GIT geschreven, maar als Git of git. git is inderdaad wel een interessant systeem, en lekker snel. Mercurial is echter simpeler in het gebruik (met name veel intuitiever als je van iets als Subversion komt) en werkt beter op Windows.

Een voordeel van DVCS is vaak ook dat je commits kleiner worden, wat historie weer makkelijker te lezen/traceren maakt. Dit wordt mogelijk gemaakt doordat een commit geen contact meer hoeft te maken met de server -> het toevoegen van een changeset is zo goed als instant.

[Morax]

Mr_Light schreef op woensdag 11 februari 2009 @ 13:49:
[...]
In een gecontroleerde/corparate omgeving is er toch al iemand aangewezen die verantwoordelijk is voor een bepaald product. als iedereen gewoon vraagt aan hem om te pullen en als hij conflicten tegen komt etc.
[...]

Dat doet dus het hele idee van "distributed" teniet! Zoals Linus zelf zei in de google presentatie: "No one's branch is more important than the other's."

Wat jij nu voorstelt is het gebruik van een distributed versiebeheersysteem om die dan toe te passen in een centrale context Op die manier loop je dan namelijk weer tegen hetzelfde probleem aan: Ik moet met de verantwoordelijke persoon kunnen verbinden om de wijzigingen door te krijgen die anderen hebben gedaan.

Dat is hetzelfde als een centraal systeem, met het enige verschil dat de centrale versie nu niet op een server staat, maar op iemands lokale computer...

[Verwijderd]

Morax schreef op woensdag 11 februari 2009 @ 14:28:
[...]


Dat doet dus het hele idee van "distributed" teniet! Zoals Linus zelf zei in de google presentatie: "No one's branch is more important than the other's."

Technisch gezien misschien niet, maar Linus is toch echt de belangrijkste. En hij pullt van een aantal mensen die de subsystems beheren. Als er dan iets fout gaat, gaat hij dat echt niet oplossen. Dan zegtie tegen de 2 conflicterende partijen dat ze van elkaar moeten pullen en de boel oplossen.

Git-blame is ook een leuke feature: dan kan je zien wie een bepaalde regel heeft geschreven. Die persoon mag dus de boel gaan oplossen als het fout is.
http://book.git-scm.com/5_finding_issues_-_git_blame.html

[ Voor 15% gewijzigd door Verwijderd op 11-02-2009 15:40 ]

[Woy]

Verwijderd schreef op woensdag 11 februari 2009 @ 15:36:
[...]

Technisch gezien misschien niet, maar Linus is toch echt de belangrijkste. En hij pullt van een aantal mensen die de subsystems beheren. Als er dan iets fout gaat, gaat hij dat echt niet oplossen. Dan zegtie tegen de 2 conflicterende partijen dat ze van elkaar moeten pullen en de boel oplossen.

Git-blame is ook een leuke feature: dan kan je zien wie een bepaalde regel heeft geschreven. Die persoon mag dus de boel gaan oplossen als het fout is.
http://book.git-scm.com/5_finding_issues_-_git_blame.html

SVN heeft ook gewoon een Blame, dus dat is niet uniek voor Git

[.oisyn]

Perforce heeft een timelapse view tooltje, dan kun je een sourcefile bekijken en heb je een tijdbalk die je kunt verslepen om op die manier precies te zien hoe (en door wie) de file gechanged is.

[kenneth]

Oh dat is helemaal cool. Zo cool trouwens dat iemand svn-time-lapse-view heeft gemaakt, geinspireerd door die tool. Alhier te zien.

Mooi woord, alhier.

[Verwijderd]

Hmm, dat heeft wel wat weg van gitk:

[kenneth]

You are in a maze of twisty little passages, all alike

[Mr_Light]

Morax schreef op woensdag 11 februari 2009 @ 14:28:
[...]

Dat doet dus het hele idee van "distributed" teniet! Zoals Linus zelf zei in de google presentatie: "No one's branch is more important than the other's."

Die branch waarvan jij de binaries bouwt en op je pc/server zet die is het belangerijkst
Die branch waar jij je product van bouwt en je naam en reputatie bij zet, die is het belangerijkst

afhankelijk van je perspectief is er altijd een branch die het belangerijkst is en in veel gevallen is het je eigen branch. En als je dus het systeem als geheel beschouwd is er dus weer geen branch meer belangerijk

Morax schreef op woensdag 11 februari 2009 @ 14:28:
Op die manier loop je dan namelijk weer tegen hetzelfde probleem aan: Ik moet met de verantwoordelijke persoon kunnen verbinden om de wijzigingen door te krijgen die anderen hebben gedaan.

Nee hoor je kan ook zelf bij die mensen langs gaan waar hij weer van pulled. Hoe dan ook zo dra er mensen dingen met elkaar sharen krijg je een gerichte graaf waarbij er altijd wel een punt die beter verbonden is dan een ander punt. Voor nieuwkomers zijn die punten weer interessant etc etc.

[ Voor 3% gewijzigd door Mr_Light op 11-02-2009 16:53 ]

[Erkens]

djc schreef op woensdag 11 februari 2009 @ 14:07:
Alleen al het feit dat je er een ander commando voor nodig hebt vond ik irritant. En dan moet je nog een aparte checkout maken (bij hg init heb je meteen al een working directory). Plus dat Mercurial veel sneller is.

Het is natuurlijk ook echt iets wat je meerdere keren per dag doet natuurlijk, zo'n repository opzetten
Dat je een "ander" commando nodig hebt bij svn is juist een voordeel, het normale commando 'svn' gebruik je op de client en 'svnadmin' gebruik je op de server: minder verwarring.

[user109731]

Hier voor werk, universiteit en thuis als het even kan SVN of Mercurial.

Voordeel van Mercurial vind ik dat je geen hidden directories in submappen hebt (geen "svn export" meer nodig). Negeren van bestanden gaat in SVN met een svn:ignore property, die moet je bij nieuwe mappen opnieuw instellen. Bij Mercurial heb je in de project-root een verborgen .hgignore bstand met daarin de patterns, werkt IMHO veel transparanter (ook wel aardig is dat er een webserver ingebouwd is, als je die opstart kun je vanaf een andere pc snel patches/bestanden inzien)

Ik ga binnenkort ook eens spelen met Bazaar. Gemaakt door het bedrijf achter Ubuntu en het schijnt erg eenvoudig in gebruik te zijn

[frickY]

Jammer dat dit topic meteen in de details duikt, en niet iets informatiever is. Maar dat zal er mee te maken hebben dat het een afsplitsing uit een bestaand topic is.

We overwegen een VCS op kantoor te introduceren, waar we met een man of 15 gezamelijk aan diverse internetprojecten werken. Voornaamste probleem nu is vaak dat als persoon A een error veroorzaakt persoon B, C en D daar last van hebben. Daarnaast missen we ook een stukje versie historie.
Nu was ik van mening dat Subversion voor ons bestemd was, maar zie hier nu weer een aantal pakketten voorbij komen waar ik nog nooit van gehoord had, ik heb dus nog wat te lezen

Voelt iemand er wat voor dit topic te voorzien van een meer informatie topicstart, opdat degene die nog niet hebben gewerkt met een VCS, zoals ondertekende, zich wegwijs kunnen maken?

[CodeCaster]

Ik heb de afgelopen paar maanden een hoop gelezen over versiebeheer en het SVN book beantwoord een enorme hoop vragen.

Ik heb nog wel een aantal specifieke vragen waar ik zelf nog niet uitkom (potentiële topics?), iets met geen zin hebben om per pc een webserver te moeten inrichten (logisch) en waar dan wel php-projecten naartoe te checkouten (samba-share per gebruiker naar een door Apache gehoste folder?).

Ook heeft Zend Studio for Eclipse een leuke optie, "check out as folder in existing project", waarmee je svn:externals aanmaakt. Helaas wordt je workspace èn je repository vernacheld wanneer je vervolgens vanuit Eclipse een external probeert te verwijderen...

[user109731]

frickY schreef op woensdag 11 februari 2009 @ 22:36:
We overwegen een VCS op kantoor te introduceren, waar we met een man of 15 gezamelijk aan diverse internetprojecten werken. Voornaamste probleem nu is vaak dat als persoon A een error veroorzaakt persoon B, C en D daar last van hebben. Daarnaast missen we ook een stukje versie historie.

15 man? Dan ga je een hoop plezier beleven aan een VCS

Misschien kun je het beste beginnnen met SVN. Het word veel gebruikt en er zijn goede tools voor (IDE-plugins, TortoiseSVN, etc.). Bovendien is de basis erg eenvoudig: er is een centrale server waar je code van download ('checkout') en upload ('commit').

Bij CVS/SVN is het zo dat iedereen lokaal alleen de laatste versie heeft, voor een diffje of het bekijken van de logs moet je verbinding met de server maken. Mercurial, Git en Bazaar zijn gedistribueerd, dit is meer een p2p-model: iedereen heeft de volledige historie lokaal, zodat diffs, logs en commits erg snel zijn. Je kunt lokaal committen en besluiten om jouw branch te 'pushen' naar een centrale server. Of 'pullen' van een repository van een collega, etc. Zie voor een betere uitleg het Mercurial Book.

CodeCaster schreef op woensdag 11 februari 2009 @ 22:50:
Ik heb nog wel een aantal specifieke vragen waar ik zelf nog niet uitkom (potentiële topics?), iets met geen zin hebben om per pc een webserver te moeten inrichten (logisch) en waar dan wel php-projecten naartoe te checkouten (samba-share per gebruiker naar een door Apache gehoste folder?).

Per pc? Als je op 1 pc een server installeert kun je op de clients gewoon een checkout daarvan doen en daarnaar committen. SVN kun je met svnserve draaien als service/daemon. Je kunt het dan ook over SSH tunnellen met svn+ssh:// urls. Let icm. Samba op dat je het juiste database-formaat gebruikt (FSFS), BerkeleyDB kan problemen veroorzaken...

[ Voor 25% gewijzigd door user109731 op 11-02-2009 23:21 ]

[MBV]

Ik kan geen vergelijking neerzetten (werk alleen maar met SVN, en als ik zie hoeveel gedoe dat oplevert met collega's ), maar als iemand een TS uitwerkt wil ik hem best wel neerzetten.

Probleem wat ik vandaag tegenkwam:
- collega had een map verplaatst met explorer. Vervolgens is die map remote verwijderd, en wordt niet meer toegevoegd, omdat TortoiseSVN denkt dat de map netjes up-2-date is. Bestandje in die map committen geeft de foutmelding dat bestand 16-f ontbreekt op de server (fileshare ingericht als svn repository, don't ask ) Cleanup helpt niet
- mergen van conflicten is een hel. Ik vind, zeker de plugin in Eclipse van tigris, mergen ontzettend makkelijk: even nalopen wat er remote gewijzigd, zorgen dat dat lokaal aankomt, en 'mark as merged'. Met vimdiff ben ik ook best handig geworden Maar als je dat nog nooit hebt gedaan is het drama niet te overzien

[Verwijderd]

Ik zou in ieder geval een geen gecentraliseerd systeem gebruiken zoals CVS of Subversion. Omdat het gecentraliseerd is, is elke commit een moment waarop je bang bent dat de boel breekt. Dan ga je namelijk de laatste versie ophalen van de server, jouw veranderingen mergen, en uploaden. Dat wil je dus eigenlijk zo min mogelijk doen. Ja, je weet dat je het eigenlijk zo vaak mogelijk moet doen om geen conflicten te krijgen, maar je hebt niet altijd iets dat al helemaal klaar is om centraal op de server te komen.

Met een verspreid systeem zoals Git, Mercurial, Bazaar, Monotone, BitKeeper wordt elke commit lokaal gedaan. Je kan gewoon na elk stukje probeersel een commit doen en zeggen wat je gedaan hebt. No pressure. Het wordt dan eigenlijk een soort Ctrl+S reflex. Pas als je denkt dat je iets waardigs hebt, dan komt het bange moment waarop je gaat mergen met de grote repository op de server. Je kan dan brokken code mergen wanneer je wilt, terwijl jij op jouw systeem altijd je eigen history hebt.

Mergen is trouwens absoluut geen hel op een gedistribueerd systeem. Je doet het waarschijnlijk elke dag wel 10 keer. (Dat is als je op die manier werkt... voor elke nieuwe richting een nieuwe branch maken. Anders zal je wat minder branches hebben om te mergen.)

[ Voor 6% gewijzigd door Verwijderd op 12-02-2009 00:38 ]

[CodeCaster]

JanDM schreef op woensdag 11 februari 2009 @ 22:57:
Per pc? Als je op 1 pc een server installeert kun je op de clients gewoon een checkout daarvan doen en daarnaar committen. SVN kun je met svnserve draaien als service/daemon. Je kunt het dan ook over SSH tunnellen met svn+ssh:// urls. Let icm. Samba op dat je het juiste database-formaat gebruikt (FSFS), BerkeleyDB kan problemen veroorzaken...

Het gaat mij meer om het testen van de geschreven code in php. Je hebt te maken met databaseverbindingen, php-modules en weet ik wat niet meer, die wil je centraal beheren. Je 'local working copy' of je workspace zeg maar.

Het lijkt me niet echt nuttig om na iedere bewerking te moeten opslaan, committen en te refreshen op de ontwikkel-url.

[kenneth]

Verwijderd schreef op donderdag 12 februari 2009 @ 00:26:
Ik zou in ieder geval een geen gecentraliseerd systeem ...
Met een verspreid systeem ...

Wat een lulverhaal. Die commit komt er, linksom of rechtsom. Alsof je met het uitstellen van dat 'bange moment' maar iets gaat bereiken.

Een distributed SCM is een centralised SCM met een extra laag. Als je iets wil leren kan je het beter simpel houden, ergo gewoon lekker centralised. Weinig complexiteit is een goede zaak.

[ Voor 23% gewijzigd door kenneth op 12-02-2009 00:34 ]

[Verwijderd]

kenneth schreef op donderdag 12 februari 2009 @ 00:31:
[...]

Die commit komt er, linksom of rechtsom. Alsof je met het uitstellen van dat 'bange moment' maar iets gaat bereiken.

Die commit komt er inderdaad. Maar je stelt het niet uit met een gedistribueerd systeem. Je stelt het uit met een gecentraliseerd systeem. Met een gedistribueerd systeem maak je elke paar minuten een commit, en af en toe merge je met anderen. Met een gecentraliseerd systeem moet je anderen niet in de weg zitten, dus ga je alles wat je doet pas committen als het werkt. Je gaat het natuurlijk niet testen tussendoor, want dan ben je daar weer te lang mee bezig, en heb je intussen misschien conflicten gekregen.

Een distributed SCM is een centralised SCM met een extra laag. Als je iets wil leren kan je het beter simpel houden, ergo gewoon lekker centralised. Weinig complexiteit is een goede zaak.

Een gecentraliseerd systeem is een systeem dat niet volledig is, en daarom gewoon broken is. Je gaat niet iets waardevols leren door met een fundamenteel slecht systeem te werken.

[MBV]

@DOT: oneens. Waarschijnlijk kan je het vergelijken met alle andere systemen die beter zijn door meer flexibiliteit aan te bieden: doordat er meer mogelijkheden zijn, is het complexer te begrijpen. Dat jij snapt hoe het werkt, wil nog niet zeggen dat je nieuwe collega, die nog nooit een VCS heeft gezien, het ook snapt.

Met SVN doe ik continue commits, als het lang gaat duren maak ik een branch aan.

[kenneth]

Oh mijn hemel. distributed scms komen net om de hoek kijken en opeens zijn centralised scms die al jaren goed functioneerden opeens broken.

Het zal allemaal wel.

[Verwijderd]

Maar er valt conceptueel weinig te leren aan een gedistribueerd systeem. Het is hoe je normaal gesproken ook werkt: jij bent je eigen werk. Je hebt je eigen history.

Pas als je gaat samenwerken krijg je te maken met andere mensen. Dan ga je zeggen: hey ik wil jouw aanpassingen hebben. Die pull je dan.

Zo werkt dat fundamenteel gezien. In een centraal systeem ga je die fundamentele werkwijze proberen te emuleren: je hebt branches die voor iedereen beschikbaar zijn, maar die zijn eigenlijk "van jou". Dat is jouw werk. En je bent constant op iemand anders z'n computer (de server) aan het committen, terwijl dat eigenlijk alleen jou aangaat.

Het is dus eigenlijk makkelijker te snappen hoe de concepten van een gedistribueerd systeem werken, dan die van een centraal systeem.

[drm]

DOT:
Maar er valt conceptueel weinig te leren aan een gedistribueerd systeem. Het is hoe je normaal gesproken ook werkt: jij bent je eigen werk. Je hebt je eigen history.

Pas als je gaat samenwerken krijg je te maken met andere mensen. Dan ga je zeggen: hey ik wil jouw aanpassingen hebben. Die pull je dan.

Zo werkt dat fundamenteel gezien. In een centraal systeem ga je die fundamentele werkwijze proberen te emuleren: je hebt branches die voor iedereen beschikbaar zijn, maar die zijn eigenlijk "van jou". Dat is jouw werk. En je bent constant op iemand anders z'n computer (de server) aan het committen, terwijl dat eigenlijk alleen jou aangaat.

Het is dus eigenlijk makkelijker te snappen hoe de concepten van een gedistribueerd systeem werken, dan die van een centraal systeem.

Daar ben ik het niet helemaal mee eens. Begrijp me goed dat ik zeker wel het hier door jou genoemde voordeel zie van een gedistribueerd systeem, maar conceptueel verschillen ze eigenlijk helemaal niet. Het concept is namelijk dat jij wijzigingen kunt delen met anderen, dat van die wijzigingen een historie wordt bijgehouden, en je bij voorkeur verschillende "routes" kunt kiezen voor die wijzigingen. That's it. Distributed heeft dan, volgens mij, alleen nog maar een technisch voordeel, namelijk dat je lokaal (= snel, scheelt netwerk verkeer, je kan lekker rommelen zonder dat iemand daar iets van ziet enzovoorts) werkt, in plaats van dat je op een server werkt. Maar dat is conceptueel helemaal niet anders.

Als typering van bovenstaande: het concept "branches" bestaat eigenlijk helemaal niet in SVN. Je werkt gewoon in een mapje in de repository. Vind je het handig dat dat een kopie is van een ander mapje en dat je de changes terug kunt mergen? Dat kan. Heet dat een branch? "Moet jij weten", hoor je svn denken. Maar er is niks aan SVN wat jou tegenhoudt om iedereen zijn eigen mapje te geven, en die mapjes onderling met elkaar te mergen, en misschien wel helemaal niet met een trunk te werken, maar alleen maar met tags. Whatever.

Al met al komt volgens mij 80% van het succes van een VCS voort uit onderlinge afspraken en vooral met elkaar blijven praten, niet de tool die je kiest. De tool die je kiest is die andere 20%, ik zou bijna zeggen, "gezwets in de marge". Ik vind die 80% dan ook veel interessanter, eerlijk gezegd

[Verwijderd]

Nouja, snelheid, en het feit dat je niemand anders in de weg zit, heeft wel een flinke impact op hoe je werkt. Branchen en mergen wordt er een stuk laagdrempeliger door. Dat noem ik eigenlijk wel een fundamenteel verschil.

Een gedistribueerd systeem is een persoonlijke tool, terwijl een centraal systeem iets is dat vanuit het bedrijf wordt opgedragen, maar waar je zelf eigenlijk weinig aan hebt.

Met een centraal systeem ga je echt niet 10 branches per dag maken. En je gaat al helemaal niet met 10 andere branches mergen als je daar niet een hele goede reden voor hebt.

In een gedistribueerd systeem kan je met een groepje developers van een bepaald gedeelte van de code samenwerken, en dus van elkaar pullen, en dan na het getest te hebben de resultaten laten pullen door de maintainer van de gehele codebase.

Zoiets is een logische manier van werken, omdat de tools ervoor gemaakt zijn. Bij een centraal systeem is zoiets slechts een mogelijke emulatie. Je moet eerst die concepten leren toe te passen in een centraal systeem, je moet naming conventions voor je branches leren, je moet je eraan houden...

[Sardaukar]

+1 voor Cheeseman.

Ik werk zelf al enige tijd met Git (op Windows). Is met de commandline tool prima te doen. Visual Studio ondersteuning zoek ik nog wel, maar is niet onmisbaar.

In een project waar ik mee bezig ben zijn we bezig om Team Foundation Server (een centraal VCS) te vervangen door een DVCS. Een ander, groot voordeel van een DVCS wat ik namelijk nog niet gelezen had in deze thread, is dat de merges veel eenvoudiger zijn in vergelijking tot een VCS. Dit is mogelijk omdat een DVCS meer informatie tot zijn beschikking heeft om een juiste keuze met betrekking tot mergen te nemen.

Ik heb in TFS meerdere malen (waarvan 2 zelfs hebben geleid tot een hotfix van Microsoft) zeer lastige merges door moeten voeren die in een latere test met Git ontzettend eenvoudig bleken.

Neem dan nog de 'herschrijf geschiedenis' mogelijkheden in Git zoals 'rebase' of 'squash' en je beseft dat je een hele krachtige tool in handen hebt. Maar inderdaad, de leercurve is ietwat complexer als bij een VCS.

[HawVer]

Git is een mooie omgeving, het is alleen jammer dat de tools nogal matig zijn.

[kenneth]

Verwijderd schreef op donderdag 12 februari 2009 @ 01:42:
Een gedistribueerd systeem is een persoonlijke tool, terwijl een centraal systeem iets is dat vanuit het bedrijf wordt opgedragen, maar waar je zelf eigenlijk weinig aan hebt.

Ja, en het bedrijf is er voor mij. Guess again. We zitten niet voor onszelf te ontwikkelen, de bedoeling is dat we samen iets maken, dat we één product opleveren. Niet dat iedereen met een eigen versie zit en naar willekeur elkaars wijzigingen opnemen.

En nogmaals: je moet nog steeds mergen, je doet alsof conflicten dan spontaan verdwijnen. Het punt van mergen stel je alleen maar uit. En je merget meerdere commits tegelijk. Natuurlijk krijg je geen conflicten als je besluit niet te mergen/pullen, maargoed, ik denk dat de meeste bazen er niet echt blij van worden als iedere developer op de afdeling met hun eigen versie komen. "Ja baas, pull maar de versie die u wil"

In een gedistribueerd systeem kan je met een groepje developers van een bepaald gedeelte van de code samenwerken, en dus van elkaar pullen, en dan na het getest te hebben de resultaten laten pullen door de maintainer van de gehele codebase.

Wat in veel situaties heel goed kan zijn, maar dat maakt een centralised scm echt niet overbodig of slecht.

Zoiets is een logische manier van werken, omdat de tools ervoor gemaakt zijn. Bij een centraal systeem is zoiets slechts een mogelijke emulatie. Je moet eerst die concepten leren toe te passen in een centraal systeem, je moet naming conventions voor je branches leren, je moet je eraan houden...

Dat is alleen maar een goed iets. Je hebt toch ook (naming) conventions in je code?

Ik krijg een beetje het idee dat je cowboy coding loopt te promoten En dat in groepsverband