[alg] Ervaringen met Source Control systemen.

[Sardaukar]

HawVer schreef op donderdag 12 februari 2009 @ 09:14:
Git is een mooie omgeving, het is alleen jammer dat de tools nogal matig zijn.

Kijk anders ook eens naar Git Extensions. Dit is een shell extension en Visual Studio plugin voor Git.

Zelf (helaas) nog niet getest. Ik ga er nog wel mee aan de gang om te zien of het handig is voor mensen die liever niet vanaf de commandline werken.

[Sardaukar]

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

Jammer dat je dat idee hebt.

Laat ik eens een praktisch voorbeeld geven om aan te geven waarom DVCS een superset van VCS is.

Met een DCVS heb ik de mogelijkheid om lokaal in mijn eigen repository lokale branches aan te maken. Ik kan bijvoorbeeld per te ontwikkelen feature een branch aanmaken. Ik kan echter ook een branch maken om wat experimenten uit te voeren. Mocht zo'n experiment geen goede code opleveren, verwijder ik simpelweg de branch.

Het is voor mij niet ongebruikelijk dat ik meerdere lokale branches heb.

Andere collega's van mij zien deze branches niet omdat ze lokaal zijn. Pas op het moment dat ik besluit dat ze goed zijn kan ik ervoor zorgen dat ik ze zelf push naar een centrale repository (of ik bied ze ter beoordeling aan bij een integrator). Op dat moment kan iedereen die wijzigingen binnenhalen.

"Nou en?" denk je misschien. "Datzelfde kan ook met een VCS". Inderdaad, maar in een VCS moet jij expliciet die branches aanmaken op het centrale systeem. In veel organisaties kan niet iedereen een branch aanmaken en moet je daarvoor een verzoek doen.

Jij zult vervolgens ook moeten aangeven waar die branches voor zijn en welk kwaliteitslabel jij daaraan geeft. Anderen zien misschien je branches staan en vragen zich af wat daar mee bedoeld wordt. Terwijl je dat eigenlijk helemaal niet wilt - die branches zijn alleen voor jouw lokale gebruik van belang.

Kijk anders eens een dagje naar Mercurial. Is net iets gebruikersvriendelijker dan Git en kent dezelfde concepten. Heeft bovendien ook goede documentatie .

[Cartman!]

Ik werk hier ook met SVN (TortoiseSVN) en opzich werkt het top. Alleen vanwege de werking van het interne netwerk (syncende servers) wil een repos nogal eens corrupt raken en dat is enorm irritant natuurlijk... Binnenkort komt als-t-goed-is er een losse SVN server zodat we daar geen last meer van kunnen hebben. Het enige nadeel vind ik de .svn mapjes. Zelf let ik er altijd op dat ik eerst n export doe voordat ik ga uploaden naar FTP maar sommigen denken daar niet aan en uploaden vrolijk 300MB data voor 6 x 10MB .swf's

[kenneth]

Sardaukar schreef op donderdag 12 februari 2009 @ 09:52:
[...]


Jammer dat je dat idee hebt.

Laat ik duidelijk zijn: ik bedoel niet dat ik denk dat distributed scms cowboy coding promoten, maar zoals DOT het aangeeft wel. Ik vind distributed scms prachtige dingen, maar dan moeten we niet opeens gaan doen alsof centralised scms opeens slecht, onbegrijpbaar of nooit nuttig zijn.

Laat ik eens een praktisch voorbeeld geven om aan te geven waarom DVCS een superset van VCS is.

Ik heb zelf allang gezegd dat DVCS een superset van VCS is, dus daar zijn we het over eens Maar toch bedankt voor je voorbeeld

Kijk anders eens een dagje naar Mercurial. Is net iets gebruikersvriendelijker dan Git en kent dezelfde concepten. Heeft bovendien ook goede documentatie .

Heb ik ook al gedaan, en ben er erg gecharmeerd van. In onze bedrijfssituatie is een gecentraliseerd scm alleen praktischer vonden wij

[Sardaukar]

Heb ik ook al gedaan, en ben er erg gecharmeerd van. In onze bedrijfssituatie is een gecentraliseerd scm alleen praktischer vonden wij

Ok, bedankt voor het duidelijk maken van je standpunt.

Laatste puntje dan

Je kunt ook met een centraal systeem werken en lokaal met een DVCS. Git heeft de mogelijkheid om met SVN te communiceren. Op deze manier kun je zelfs in een centrale omgeving lokaal met Git werken.

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 10:12:
[...]
Je kunt ook met een centraal systeem werken en lokaal met een DVCS. Git heeft de mogelijkheid om met SVN te communiceren. Op deze manier kun je zelfs in een centrale omgeving lokaal met Git werken.

Dat lijkt me wel interessant. Wij gebruiken ook SVN, en op zich voldoet dat perfect aan onze wensen in het bedrijf. Soms heb ik echter wel behoefte om even snel lokaal een branch te maken om wat uit te proberen, en dan vind ik het nogal overkill om op de server een branch te maken, aangezien het dan nogal vervuilend werkt.

Ik zal eens kijken of dat een beetje werkbaar is.

[MBV]

Als git door meer info bij te houden minder vaak conflicten geeft met merges, dan is dat een groot voordeel. Weet er iemand een goede noob-proof uitleg? Niet dat ik mezelf als noob inschat, maar om aan collega's o.i.d. aan te bieden.
Een noob-proof uitleg van werken met SVN zou ook welkom zijn.

[Sardaukar]

MBV schreef op donderdag 12 februari 2009 @ 10:40:
Als git door meer info bij te houden minder vaak conflicten geeft met merges, dan is dat een groot voordeel. Weet er iemand een goede noob-proof uitleg? Niet dat ik mezelf als noob inschat, maar om aan collega's o.i.d. aan te bieden.
Een noob-proof uitleg van werken met SVN zou ook welkom zijn.

Het korte antwoord:

Git bewaart de history van beide branches ook na een merge. Meerdere merges van dezelfde branches worden standaard ondersteunt. Ook werkt Git niet met een los bestand als concept - het werkt met snapshots van de gehele tree.

Zie voor meer uitleg ook hier http://nathanj.github.com/gitguide/

[kenneth]

Wat ik niet snap --en dat kan heel goed aan mij liggen-- is waarom het minder vaak conflicten zou geven. Als een Linus en een Alan (om maar eens twee namen te noemen ) dezelfde regel code in hetzelfde bestand wijzigen, dan is daar toch geen scm dat daar iets tegen doet? Conflicten worden niet veroorzaakt door een scm zelf, het kan ze alleen constateren en eventueel (deels) oplossen. Maar dat houdt ook op op een gegeven moment.

[Verwijderd]

Ik kan echt iedereen ClearCase aanraden, vooral bij meer dan 1 gebruiker ( ).

[Sardaukar]

kenneth schreef op donderdag 12 februari 2009 @ 10:59:
Wat ik niet snap --en dat kan heel goed aan mij liggen-- is waarom het minder vaak conflicten zou geven. Als een Linus en een Alan (om maar eens twee namen te noemen ) dezelfde regel code in hetzelfde bestand wijzigen, dan is daar toch geen scm dat daar iets tegen doet? Conflicten worden niet veroorzaakt door een scm zelf, het kan ze alleen constateren en eventueel (deels) oplossen. Maar dat houdt ook op op een gegeven moment.

De conflicten die jij noemt houd je natuurlijk altijd.

- Alan maakt een change in foo.txt op een bepaalde regel.
- Linus doet hetzelfde maar dan met een andere inhoud.

Als je dit rechtstreeks gaat mergen heb je een conflict.

- Alan maakt een change in foo.txt op een bepaalde regel.
- Linus doet hetzelfde maar dan met een andere inhoud.
- Alan pusht zijn wijzigingen naar zijn publieke repository.
- Alan roept naar Linus dat hij nieuwe wijzigingen op zijn publieke repository heeft.
- Linus pullt die wijzigingen binnen en probeert deze te mergen. Conflict wordt gedetecteerd en moet opgelost worden.
- Linus lost dit op en pusht weer naar zijn publieke repository.

Er is echter ook een andere mogelijkheid: rebase

- Alan maakt een change in foo.txt op een bepaalde regel.
- Linus doet hetzelfde maar dan met een andere inhoud.
- Alan pusht zijn wijzigingen naar zijn publieke repository.
- Alan roept naar Linus dat hij nieuwe wijzigingen op zijn publieke repository heeft.
- Linus doet een fetch. De wijzigingen worden binnengehaald maar nog niet gemerged.
- Linus voert een rebase uit. Zijn eigen wijzigingen worden tijdelijk opzij gezet, de wijzigingen van Alan worden doorgevoerd EN DAARNA worden pas de eigen wijzigingen van Linux doorgevoerd.

Dit gaat verbazingwekkend vaak goed. Let wel: een merge conflict is altijd mogelijk.

Ik kan je uit de praktijk vertellen dat merge conflicten minder vaak optreden en vaak niet zo groot zijn.

Deze discussie legt het ook wel aardig uit.

[ Voor 2% gewijzigd door Sardaukar op 12-02-2009 11:22 . Reden: URL toegevoegd. ]

[Voutloos]

Cartman! schreef op donderdag 12 februari 2009 @ 10:02:
Het enige nadeel vind ik de .svn mapjes. Zelf let ik er altijd op dat ik eerst n export doe voordat ik ga uploaden naar FTP maar sommigen denken daar niet aan en uploaden vrolijk 300MB data voor 6 x 10MB .swf's

Dat is geen nadeel. Het Echte Probleem is dat er dan blijkbaar geen goede deployment strategie die binnen je bedrijf consistent toegepast wordt. Het uploaden van wat meta data is dan nog wel een van je minst erge zorgen.

kenneth schreef op donderdag 12 februari 2009 @ 10:59:
Wat ik niet snap --en dat kan heel goed aan mij liggen-- is waarom het minder vaak conflicten zou geven.

Ligt niet aan jou hoor. Ik ziet het ook niet zo. Conflicten blijven, tenzij je tijdens check out als alles lockt. Het argument dat je met SVN per se grotere, moeilijkere commits doet is echt bullshit.

[Mr_Light]

frickY schreef op woensdag 11 februari 2009 @ 22:36:
Voornaamste probleem nu is vaak dat als persoon A een error veroorzaakt persoon B, C en D daar last van hebben.

https://hudson.dev.java.net/ gaat denk ik meer helpen dan

[kenneth]

Verwijderd schreef op donderdag 12 februari 2009 @ 11:11:
Ik kan echt iedereen ClearCase aanraden, vooral bij meer dan 1 gebruiker ( ).

Gezien de aard van het topic horen we graag waarom

[bat266]

Het lijkt me inderdaad handig om lokaal je history bij te houden en dat je terug kunt naar een savepoint zullen we maar zeggen, zonder dat je de boel naar een centrale repos gepushed hebt. Branches zouden dit probleem ook kunnen oplossen, maar ik ga niet vaak een branch maken van max 2 dagen werk en dan zou een eigen lokale branch wel handig kunnen zijn.

[kenneth]

Wat is er trouwens zo lastig aan shortliving branches? Het zijn twee extra commando's (branch en later merge of delete), en je houdt je history intact terwijl je er niet continu mee lastig gevallen wordt, aangezien (bij svn dan) hij niet in de history van je trunk zit, enkel in die van de folder erboven.

[Sardaukar]

kenneth schreef op donderdag 12 februari 2009 @ 12:14:
Wat is er trouwens zo lastig aan shortliving branches? Het zijn twee extra commando's (branch en later merge of delete), en je houdt je history intact terwijl je er niet continu mee lastig gevallen wordt, aangezien (bij svn dan) hij niet in de history van je trunk zit, enkel in die van de folder erboven.

Extra administratieve overhead in mijn ogen:

• Toegang tot server nodig. Misschien heb jij de rechten wel niet of moet je door een proces heen om een branch aan te laten maken. Misschien is de server wel off-line voor maintenance
• Branches zijn voor iedereen zichtbaar terwijl je dat misschien niet wilt.

Je history blijft overigens ook intact bij Git.

Je ziet het het beste bij een schaalvergroting. Stel, ik heb 5 programmeurs die samenwerken aan een project. Ze hebben allemaal een aantal features waar ze aan willen werken. Per feature maak je een branch zodat je in de history alles later goed kan relateren. Stel dat ze 3 branches per persoon aanmaken.

Nu zou ik in Subversion dus ineens 15 branches zien.

In de praktijk merk je dat mensen in een VCS minder snel een branch aanmaken door dit soort redenen. Terwijl het in Git reuze eenvoudig en snel is. Vergis niet: snelheid is ook een factor. Ik heb hier 3 miljoen regels aan source liggen. Met 1 commando maak ik een nieuwe branch aan en schakel ik naar deze branch om. Tijd: minder dan een seconde.

Juist door dit soort performance ga je veel meer met branches doen.

[djc]

MBV schreef op donderdag 12 februari 2009 @ 10:40:
Als git door meer info bij te houden minder vaak conflicten geeft met merges, dan is dat een groot voordeel. Weet er iemand een goede noob-proof uitleg? Niet dat ik mezelf als noob inschat, maar om aan collega's o.i.d. aan te bieden.
Een noob-proof uitleg van werken met SVN zou ook welkom zijn.

Een goede uitleg van DVCS vind je hier:

http://betterexplained.co...sion-control-illustrated/

De betere merge van DVCS komt ook van het feit dat DVCS bijhouden wat er precies aan vooraf ging, wat er aan geschiedenis al gemerged is.

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 12:27:
[...]

• Toegang tot server nodig. Misschien heb jij de rechten wel niet of moet je door een proces heen om een branch aan te laten maken. Misschien is de server wel off-line voor maintenance
• Branches zijn voor iedereen zichtbaar terwijl je dat misschien niet wilt.

Dit zijn nog wel problemen die te overzien zijn. Hoe vaak is de SVN server nou niet toegankelijk? Bij mij ieder geval altijd.

Je ziet het het beste bij een schaalvergroting. Stel, ik heb 5 programmeurs die samenwerken aan een project. Ze hebben allemaal een aantal features waar ze aan willen werken. Per feature maak je een branch zodat je in de history alles later goed kan relateren. Stel dat ze 3 branches per persoon aanmaken.

Nu zou ik in Subversion dus ineens 15 branches zien.

Dat is inderdaad mijn bezwaar, je kunt het natuurlijk wel weer netjes ordenen, maar "persoonlijke branches" zou ik wel een voordeel vinden.

In de praktijk merk je dat mensen in een VCS minder snel een branch aanmaken door dit soort redenen. Terwijl het in Git reuze eenvoudig en snel is. Vergis niet: snelheid is ook een factor. Ik heb hier 3 miljoen regels aan source liggen. Met 1 commando maak ik een nieuwe branch aan en schakel ik naar deze branch om. Tijd: minder dan een seconde.

Juist door dit soort performance ga je veel meer met branches doen.

Branchen en switchen is in SVN ook heel snel. Ik heb tenminste nooit problemen met de performance met branchen.

Het gootste voordeel wat ik voor mezelf zie zou dus de lokale branches zijn. Als je echter op meerdere pc's ontwikkeld ( bijvoorbeeld op de zaak en thuis ) je toch zult moeten pushen naar de centrale server, of moet zorgen dat je je lokale repository vanaf overal kunt benaderen. Bij ons kan ik extern niet bij mijn dev pc komen, maar wel bij de SVN server. Natuurlijk moet ik dan ook al gecommit hebben in een branch om die wijzigingen thuis te zien, maar dat veranderd niet met een DVCS

[kenneth]

[quote]Sardaukar schreef op donderdag 12 februari 2009 @ 12:27:

• Toegang tot server nodig. Misschien heb jij de rechten wel niet of moet je door een proces heen om een branch aan te laten maken. Misschien is de server wel off-line voor maintenance

Dat kan inderdaad een nadeel zijn in bv. een OS-project waar wereldwijd op verschillende tijden wordt gewerkt. In een bedrijfsomgeving vind ik dat weer geen goede reden. Daar ga je uit van normale beschikbaarheid tijdens kantooruren, je richt je omgeving niet in op de uitzondering.
[q]
• Branches zijn voor iedereen zichtbaar terwijl je dat misschien niet wilt.Waarom niet?

Je ziet het het beste bij een schaalvergroting. Stel, ik heb 5 programmeurs die samenwerken aan een project. Ze hebben allemaal een aantal features waar ze aan willen werken. Per feature maak je een branch zodat je in de history alles later goed kan relateren. Stel dat ze 3 branches per persoon aanmaken.

Nu zou ik in Subversion dus ineens 15 branches zien.

Tja, zitten ze in de weg? De meeste gooi je weer weg en het is niet alsof je de hele dag naar branches zit te staren. Plus je hebt gewoon een goed beeld van wat er gebeurt. In een gecentraliseerde omgeving (bedrijf, je werkt aan één versie van één product onder toezicht van één teamleider) is dat ook wenselijk.

In de praktijk merk je dat mensen in een VCS minder snel een branch aanmaken door dit soort redenen. Terwijl het in Git reuze eenvoudig en snel is. Vergis niet: snelheid is ook een factor. Ik heb hier 3 miljoen regels aan source liggen. Met 1 commando maak ik een nieuwe branch aan en schakel ik naar deze branch om. Tijd: minder dan een seconde.

Is geen argument meer tegenwoordig. Branches zijn in svn en de meeste moderne scms gewoon O(1). Alleen bij systemen die de Romeinen nog gebruikten (lees: cvs) is dat niet zo.

[ Voor 3% gewijzigd door kenneth op 12-02-2009 12:57 ]

[MBV]

kenneth schreef op donderdag 12 februari 2009 @ 10:59:
Wat ik niet snap --en dat kan heel goed aan mij liggen-- is waarom het minder vaak conflicten zou geven. Als een Linus en een Alan (om maar eens twee namen te noemen ) dezelfde regel code in hetzelfde bestand wijzigen, dan is daar toch geen scm dat daar iets tegen doet? Conflicten worden niet veroorzaakt door een scm zelf, het kan ze alleen constateren en eventueel (deels) oplossen. Maar dat houdt ook op op een gegeven moment.

Als je de geschiedenis bijhoudt, kan je de volgende situatie detecteren:
versie 1: 20 regels
branch: versie b1.1 en b2.1 (branch 1 versie 1 en branch2 versie 1)
versie b1.2: regels 5-10 worden verwijderd
versie b2.2: regel 11 wordt verwijderd
versie b1.3: 5 regels na regel 5 worden toegevoegd

SVN zegt nu vrolijk: regel 5-10 zijn gewijzigd t.o.v. regel 5-11, GIT zou hier wat slims kunnen doen (bijv als de regels op elkaar lijken ze toch onder elkaar neerzetten, waar een slimme SVN-plugin zou proberen de wijzigingen over elkaar heen te zetten)

[Sardaukar]

Woy schreef op donderdag 12 februari 2009 @ 12:55:
[...]

Dit zijn nog wel problemen die te overzien zijn. Hoe vaak is de SVN server nou niet toegankelijk? Bij mij ieder geval altijd.

Altijd? Als in 100% uptime? Dan zou ik je diensten als beheerder gaan aanbieden - daar kun je goed geld mee verdienen

Het gootste voordeel wat ik voor mezelf zie zou dus de lokale branches zijn. Als je echter op meerdere pc's ontwikkeld ( bijvoorbeeld op de zaak en thuis ) je toch zult moeten pushen naar de centrale server, of moet zorgen dat je je lokale repository vanaf overal kunt benaderen. Bij ons kan ik extern niet bij mijn dev pc komen, maar wel bij de SVN server. Natuurlijk moet ik dan ook al gecommit hebben in een branch om die wijzigingen thuis te zien, maar dat veranderd niet met een DVCS

In die situatie had je natuurlijk ook gewoon je repository op USB-stick kunnen zetten. Omdat Git zijn changes in een losse .git directory bewaart, kun je er vervolgens overal mee werken.

[Sardaukar]

Is geen argument meer tegenwoordig. Branches zijn in svn en de meeste moderne scms gewoon O(1). Alleen bij systemen die de Romeinen nog gebruikten (lees: cvs) is dat niet zo.

Je vergeet iets: omdat Git de gehele history lokaal heeft, zijn alle operaties zo snel. Niet alleen operaties op de head.

Laten we er een ander scenario van maken:

• Ik ben aan het werken op mijn main codeline. Vervolgens komt er een bugmelding binnen voor een oud stuk software. Deze software heb jij ergens in het verleden (laten we zeggen: een half jaar terug) getagged.
• Omdat alle history lokaal staat kan ik nog steeds in dezelfde tijd als hierboven een branch maken, afgesplitst op de tag van hierboven. In jouw geval zal Subversion op zijn minst via het netwerk die code moeten gaan binnenhalen.

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 13:05:
[...]
Altijd? Als in 100% uptime? Dan zou ik je diensten als beheerder gaan aanbieden - daar kun je goed geld mee verdienen

Nou laat het dan 99% zijn, maar je kan meestal wel doorwerken als hij niet beschikbaar is want je hebt zowiezo je lokale working copy. En als hij er uit ligt dan heeft het toch meteen prioriteit om het weer aan de gang te krijgen. Ik kan me ieder geval niet voorstellen dat alle ontwikkelaars hier met de handen in het haar zitten omdat ze een half uurtje niet bij de SVN repository zouden kunnen.

In die situatie had je natuurlijk ook gewoon je repository op USB-stick kunnen zetten. Omdat Git zijn changes in een losse .git directory bewaart, kun je er vervolgens overal mee werken.

Dat is wel een optie, maar thuis kan ik dan bijvoorbeeld niet van een Collega pullen, dus houd je hetzelfde ( of mischien wel groter omdat mensen later naar de centrale repository committen ) connectie "probleem" als je met SVN hebt.

[Sardaukar]

Nog een handige optie van Git: git bisect.

Hiermee kan je Git geautomatiseerd laten testen wanneer een bepaalde checkin een fout heeft veroorzaakt. Nodig: een test waarmee je kan bepalen of de check-in correct is.

Je vertelt Git welke check-in nog goed was (die van vorige week bijvoorbeeld) Vervolgens vertel je aan Git welke check-in nu fout gaat (vandaag).

Vervolgens laat je Git bisect draaien. Er wordt binair in de lijst van check-ins gezocht en door de test gevoerd. Het eindresultaat is dat Git je precies laat zien wanneer het foute gedrag is geintroduceerd.

Zie voor een uitleg ook hier

Nu kun je wel gaan zeggen dat dit ook voor Subversion mogelijk is (en daar heb je ook gelijk in), alleen als je alle functionaliteiten optelt is Git voor mij stukken krachtiger als een VCS.

Let wel: daarmee wil ik niks zeggen over bedrijven die andere eisen hebben. Ik vind echter wel dat mensen argumenten vrij makkelijk opzij schuiven.

Ga het gewoon eens proberen op een hobby-project en oordeel dan nog eens.

[MBV]

Hoe doe je dat dan met SVN? Perl-scriptje-oplossing kan met elk VCS (waarvoor een CLI is).

[Verwijderd]

Branches zijn misschien O(1), maar dat boeit niet zo. Hoe zit het met merges? Als jij 10 branches per dag maakt, en ook zoveel merged (echt niet gek hoor, het is gewoon een powertool), dan wil je niet dat de merge tijd kost.

En als 20 man elke dag ~10 branches maken met een centraal systeem zit je met ~200 branches die elke dag komen en gaan.

Woy schreef op donderdag 12 februari 2009 @ 13:14:
Ik kan me ieder geval niet voorstellen dat alle ontwikkelaars hier met de handen in het haar zitten omdat ze een half uurtje niet bij de SVN repository zouden kunnen.

Neuh, dan importeren ze de tree in Git en gaan ze van elkaar pullen. Zodra de server weer up is, wordt het weer naar SVN gepusht en heeft niemand er wat van gemerkt dat het ooit ergens anders stond.

[Sardaukar]

Woy schreef op donderdag 12 februari 2009 @ 13:14:
[...]

Nou laat het dan 99% zijn, maar je kan meestal wel doorwerken als hij niet beschikbaar is want je hebt zowiezo je lokale working copy. En als hij er uit ligt dan heeft het toch meteen prioriteit om het weer aan de gang te krijgen. Ik kan me ieder geval niet voorstellen dat alle ontwikkelaars hier met de handen in het haar zitten omdat ze een half uurtje niet bij de SVN repository zouden kunnen.

Hmm, jij kunt wel een beetje lopen proggen tegen je lokale working copy met Subversion.
Je kunt echter niet:

• branchen
• diffen
• mergen
• committen

Kortom, al die dingen waarvoor je een versiebeheersysteem gebruikt.

Enne, we hadden hier met 120 developers wel eens een storing van een uur op TFS. Daar hoef ik niet met een excuus als: "Je kunt ondertussen toch wel wat anders doen" aan te komen.

Dat is wel een optie, maar thuis kan ik dan bijvoorbeeld niet van een Collega pullen, dus houd je hetzelfde ( of mischien wel groter omdat mensen later naar de centrale repository committen ) connectie "probleem" als je met SVN hebt.

Je collega had ook een repository op stick kunnen zetten. Of je collega had deze ergens op FTP kunnen zetten waar je erbij kon. Of je collega had zijn repository via HTTP toegankelijk kunnen maken.

[Sardaukar]

Nou, nog een leuke optie dan.

Git squash.

Stel, je werkt met een aantal lokale branches. Je bent bezig een feature te ontwikkelen en in een andere branch heb je wat bugs gefixt.

Het ontwikkelen van je feature heeft je nogal wat tijd gekost. Je hebt in totaal 20 commits gemaakt op je feature branch. Je wilt dit toevoegen aan de master branch en uiteindelijk pushen naar de publieke repository.

Je wilt echter liever niet dat deze 20 losse commits naar de publieke repository gaan. Het liefst heb je 1 commit waarin je beschrijft dat je deze feature hebt toegevoegd. Dat houdt de publieke repository lekker duidelijk.

Je kunt met Git dan tijdens de merge aangeven dat je de changesets vanaf de featurebranch wil samenvatten in 1 changeset in de master branch.

Ideaal tijdens user-story driven development of topic-branch development.

[ Voor 4% gewijzigd door Sardaukar op 12-02-2009 14:55 ]

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 14:28:
[...]
Enne, we hadden hier met 120 developers wel eens een storing van een uur op TFS. Daar hoef ik niet met een excuus als: "Je kunt ondertussen toch wel wat anders doen" aan te komen.

Het lijkt me dat je dan niet de juiste server neergezet hebt als het geen extreem uitzonderlijke situatie is dat de server niet beschikbaar is.

Over het algemeen is de bereikbaarheid van de VCS server gewoon toerijkend.

Begrijp me niet verkeerd, ik geloof best dat Git een mooi systeem is, en zo zijn voordelen kan hebben boven SVN.

Ik zie alleen niet het grote voordeel waarom iedereen meteen op een DVCS over zou moeten stappen. In veel bedrijfs situaties zijn de voordelen IMHO niet extreem groot.

Voor OS projecten lijken me de voordelen veel duidelijker, maar aangezien ik daar niet vaak mee bezig ben kan ik daar niet zo goed over oordelen.

[Sardaukar]

Woy schreef op donderdag 12 februari 2009 @ 15:02:
[...]

Het lijkt me dat je dan niet de juiste server neergezet hebt als het geen extreem uitzonderlijke situatie is dat de server niet beschikbaar is.

Jij kunt blijkbaar op afstand - zonder enige kennis van zaken over onze infrastructuur - bepalen wat er mis was bij ons? Dat vind ik een erg brutale uitspraak.

<sarcasme>
Maar blijkbaar leef jij in een ideale wereld waarbij je infrastructuur altijd overeind blijft en altijd beschikbaar is.
</sarcasme>

Ik zie alleen niet het grote voordeel waarom iedereen meteen op een DVCS over zou moeten stappen. In veel bedrijfs situaties zijn de voordelen IMHO niet extreem groot.

Voor OS projecten lijken me de voordelen veel duidelijker, maar aangezien ik daar niet vaak mee bezig ben kan ik daar niet zo goed over oordelen.

Mijn doel is ook niet om iedereen over te laten stappen. Waarom zou je dingen veranderen als de huidige situatie afdoende voor je is? Ik wil alleen een beeld schetsen van wat er ook mogelijk is.

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 15:42:
[...]

Jij kunt blijkbaar op afstand - zonder enige kennis van zaken over onze infrastructuur - bepalen wat er mis was bij ons? Dat vind ik een erg brutale uitspraak.

<sarcasme>
Maar blijkbaar leef jij in een ideale wereld waarbij je infrastructuur altijd overeind blijft en altijd beschikbaar is.
</sarcasme>

Ik bepaal niet wat er mis was bij jullie, maar vind je zelf ook niet dat als een VCS server een belangrijk deel in je organisatie is dat je er dan genoeg effort in moet steken om die beschikbaar te houden? Als het dan blijkbaar geen uitzondering is dat hij niet beschikbaar is, is er IMHO iets niet goed gedaan.

Mijn doel is ook niet om iedereen over te laten stappen. Waarom zou je dingen veranderen als de huidige situatie afdoende voor je is? Ik wil alleen een beeld schetsen van wat er ook mogelijk is.

Dan zijn we het eens, ik zeg ook nergens dat Git een slecht systeem is, en heb al meerdere malen gezegd dat ik er wel wat interessante opties in vind zitten, maar dat ik vind dat de "nadelen" van bijvoorbeeld SVN erg overdreven worden.

[kenneth]

Sardaukar schreef op donderdag 12 februari 2009 @ 15:42:
[...]

Jij kunt blijkbaar op afstand - zonder enige kennis van zaken over onze infrastructuur - bepalen wat er mis was bij ons? Dat vind ik een erg brutale uitspraak.

<sarcasme>
Maar blijkbaar leef jij in een ideale wereld waarbij je infrastructuur altijd overeind blijft en altijd beschikbaar is.
</sarcasme>

Dat zegt hij niet. Ridiculiseren helpt niet om je punt te maken.

Mijn doel is ook niet om iedereen over te laten stappen. Waarom zou je dingen veranderen als de huidige situatie afdoende voor je is? Ik wil alleen een beeld schetsen van wat er ook mogelijk is.

Het is zeker wel verhelderend ja

Ik kwam in die gegeven link http://betterexplained.co...sion-control-illustrated/ nog wel wat punten tegen die wat nadelen van dvcs-en gaven, op zich ook wel goed om in acht te nemen.

[Sardaukar]

Woy schreef op donderdag 12 februari 2009 @ 15:51:
[...]

Ik bepaal niet wat er mis was bij jullie, maar vind je zelf ook niet dat als een VCS server een belangrijk deel in je organisatie is dat je er dan genoeg effort in moet steken om die beschikbaar te houden. Als het dan blijkbaar geen uitzondering is dat hij niet beschikbaar is, is er IMHO iets niet goed gedaan.

Precies. Maar waar haal jij vandaan dat het geen uitzondering was dat hij niet beschikbaar was? En je springt dan meteen maar door naar de conclusie dat ons beheer wel niet voldoende zal zijn.

Ik vind dat een vreemde opmerking omdat jij niet weet wat er bij ons speelde en ook geen enkel inzicht hebt in onze infrastructuur.

Ik probeerde alleen duidelijk te maken dat zelfs bij een kleine outage (hoe goed je beheer ook is), de impact des te groter is naarmate het aantal mensen dat geraakt wordt.

[Woy]

Sardaukar schreef op donderdag 12 februari 2009 @ 15:59:
[...]
Precies. Maar waar haal jij vandaan dat het geen uitzondering was dat hij niet beschikbaar was? En je springt dan meteen maar door naar de conclusie dat ons beheer wel niet voldoende zal zijn.

Ik vind dat een vreemde opmerking omdat jij niet weet wat er bij ons speelde en ook geen enkel inzicht hebt in onze infrastructuur.

Ik probeerde alleen duidelijk te maken dat zelfs bij een kleine outage (hoe goed je beheer ook is), de impact des te groter is naarmate het aantal mensen dat geraakt wordt.

Ik reageerder op

Enne, we hadden hier met 120 developers wel eens een storing van een uur op TFS. Daar hoef ik niet met een excuus als: "Je kunt ondertussen toch wel wat anders doen" aan te komen.

"Wel eens" vat ik op als: "Niet ongebruikelijk", maar laten we het daar maar niet meer over hebben. Levert toch niks constructiefs op

[Verwijderd]

MBV schreef op donderdag 12 februari 2009 @ 13:41:
Hoe doe je dat dan met SVN? Perl-scriptje-oplossing kan met elk VCS (waarvoor een CLI is).

Bisect wordt een vervelende aangelegenheid bij SVN, omdat je telkens de revisie moet ophalen. Je zou natuurlijk de repo kunnen clonen naar een nieuwe lokale, en dan daar gaan bisecten met een zelfgemaakt scriptje, maarja, dat is een beetje omslachtig.

[MBV]

offtopic:
Zo was er een mooi script dat hier op de TU/e is geschreven, wat kon visualiseren hoe code werd bewerkt, door wie, enzovoort. Zag er heel leuk uit. Ik wilde dat toen loslaten op de CVS- of SVN-repository van een Shell-project van een half miljoen regels code ofzo. Dat ding ging dus bestandje voor bestandje, versie voor versie, de gegevens binnenhalen. De eis was dat het binnen een nacht klaar was, even snel rekenen leverde op dat het ding een week dag-en-nacht bezig zou zijn

[djc]

kenneth schreef op donderdag 12 februari 2009 @ 15:52:
Ik kwam in die gegeven link http://betterexplained.co...sion-control-illustrated/ nog wel wat punten tegen die wat nadelen van dvcs-en gaven, op zich ook wel goed om in acht te nemen.

Zoals wat?

[drm]

offtopic:
* drm vraagt zich in de tussentijd af of deze discussie zich zo langzamerhand naast de klassiekers "MS of open source" of "Linux of FreeBSD" of "Firefox of Opera" mag scharen

[Verwijderd]

offtopic:
En vim vs emacs niet te vergeten.

[roy-t]

offtopic:
O.o Opera en Kate!

Ik zie zelf eigenlijk maar vrij weinig voordelen van de distributed aanpak, vooral het mergen lijkt me ontiegelijk iritant als je alle veranderingen mee wilt nemen.

User A werkt in repository van User B en voegt aan File C regels D toe.
User E werkt ook in de repository van User B en voegt aan File C regels F toe. (tot zover nog redelijk te mergen

Nu voegt User G in de repository van User A aan File C regels H toe.
En voegt User I in de repository van User E aan File C regels J toe.l

Hoe zorg je er nu voor dat je als User X, de meest recente versie hebt van File C met zowel de wijzigingen van A, E, G en I.

-G, I en B moeten onlin zijn. (in dit geval mogelijk maar in systemen met 25+ man waar iedereen telkens wisselt van het gebruik van andermans repo moeten haast wel iedereen online zijn om echt alle veranderingen te krijgen)
-Stel G heeft een bug gefixed en een extra methode toegevoegd in de gepulde repro van A, en de code die I toegevoegd heeft aan E's repro staat daardoor op de verkeerde plek (bug fix in andere methode). GIT+ moet dan taal-aware zijn of zoeken naar bit patronen om uit-tevogelen hoe een merge tussen G, I, B eruit gaat zijn, maar wie zegt er niet dat dat bitpatroon er toevallig is (als het te kort is kan dit snel) en dat de eigenlijk code waarna de wijzingen van I moeten komen verwijdered is?

-Ook bij stukken die 2x bewerkt zijn lijkt me dit helemaal een hel, omdat het in dit geval niet 1 of 2x is zoals meestal bij een centrale repro, of niet bij een checkout repro, kan dit door de vele branches en verschillende repro's echt ontzettend de hand uitloop.

Nu de problemen bij een centrale repro:

A haalt iets uit repro 1, werkt er mee en commit.
B haalt dezelfde file uit repro 1 en commit.
C haalt ook die file uit repro 1 voordat B commit en commit deze later.

Nu heb je maar 1 probleem en het blijft allemaal een stuk overzichtelijker, hoewel je natuurlijk nogsteeds problmene kan hebben met mergen.

Bij een checkout heb je helemaal niet van dit soort problemen.

Om de pasta theorie ermaar bij te houden: Distributed is in mijn ogen zoiets als Spaghetti van verschillende stukjes lengte en dikte allemaal in een wirwar door elkaar en je probeert dit uit de knoop te halen.

Centraal is meer zoiets als Ravioli, makkelijker te scheiden maar je moet ze nog wel open maken om te kijken in welke kaas en in welke vlees/tomaat zit . (je favoriete stukje uitzoeken in het geval van een fout).

Check-out is voor mij pizza: 1 groot stuk, beetje lomp misschien maar hoppa meteen opeten!

Natuurlijk begrijp ik dat als GiT gebruikt wordt voor OA de linux kernel dat veel problemen zijn opgelost of dat dit doomscenario wel door software op te lossen is. Maar als bedrijf waar je meer invloed hebt op wie wat waar wanneer, en dat iedereen apparte taken heeft vaak, lijkt me een check-out systeem het meest robuust. (sowieso altijd het meest robuust, maar in dit geval ook het meest handige/waardevolste). In dit geval kun je natuurlijk ook naar je collega toelopen of ie even uit kan checken. .

Dus ja ik begrijp de uses voor een distrubited aanpak, maar zelf zie ik me het nog niet zo snel gebruiken en kies ik liever voor de compleet tegenovergestelde aanpak, maar ook omdat dit tot nu toe in mijn projectjes e.d. het meest handige was. (Hoewel het toch meestal uitkwam op standaard SVN zonder checkout).

Deze nadelen kwamen ook nog naar boven op de gelinkte site en vond ik wel zo belangrijk om hier neer te zetten, er wordt alleen nergens echt aangestipt over het mergen, wel deels door het "there is no latest version" probleem.

here’s not really a “latest version”. If there’s no central location, you don’t immediately know whether to see Sue, Joe or Eve for the latest version. Again, a central location helps clarify what the latest “stable” release is.

There aren’t really revision numbers. Every repo has its own revision numbers depending on the changes. Instead, people refer to change numbers: Pardon me, do you have change fa33e7b? (Remember, the id is an ugly guid). Thankfully, you can tag releases with meaningful names.

Natuurlijk voor de objectiviteit ook even de voordelen erbij (ben het er grotendeels mee eens)

Everyone has a local sandbox. You can make changes and roll back, all on your local machine. No more giant checkins; your incremental history is in your repo.

It works offline. You only need to be online to share changes. Otherwise, you can happily stay on your local machine, checking in and undoing, no matter if the “server” is down or you’re on an airplane.

It’s fast. Diffs, commits and reverts are all done locally. There’s no shaky network or server to ask for old
revisions from a year ago.

It handles changes well. Distributed version control systems were built around sharing changes. Every change has a guid which makes it easy to track.

Branching and merging is easy. Because every developer “has their own branch”, every shared change is like reverse integration. But the guids make it easy to automatically combine changes and avoid duplicates.

Less management. Distributed VCSes are easy to get running; there’s no “always-running” server software to install. Also, DVCSes may not require you to “add” new users; you just pick what URLs to pull from. This can avoid political headaches in large projects.

[ Voor 23% gewijzigd door roy-t op 13-02-2009 00:01 ]

[kenneth]

djc schreef op donderdag 12 februari 2009 @ 22:20:
[...]
Zoals wat?

Dat over backups van lokale changes. Dat vind ik toch wel een belangrijk aandachtspunt, juist omdat het allemaal zo verspreid is. En het idee van een duidelijke 'laatste versie' vind ik (in een bedrijfsomgeving) wel belangrijk.

[MBV]

Tja, daarover maak je afspraken. Net zoals je in SVN de laatste versie in /trunk hebt staan, of in /branches/working, of waar je dat maar leuk vindt.

[Verwijderd]

Linux development kan je op zich wel als een bedrijfsomgeving zien. Je hebt de grote maintainers die van anderen pullen, of waar naartoe wordt gepusht (patches over mail), en Linus pullt uiteindelijk van de grote maintainers. Linus' tree wordt als de belangrijkste gezien, en die is dus de 'laatste versie'.

Wat is in SVN de 'laatste versie' als er allemaal aparte branches zijn? Toch ook gewoon de TRUNK? Bij Git is de tree van het release team de laatste versie.

Backups moeten maken is een nadeel? Volgens mij gebeurt er een hoop buiten SVN om waar je ook backups van moet maken. Bedrijfsdocumenten enzo. Dit gaat daar gewoon bij.

[kenneth]

Daar moet je inderdaad afspraken over maken. Maar dus op het eind van de dag wordt het wel weer allemaal gecentraliseerd dus. Of je gaat ook gedistribueerde backups maken. Of wat dan ook.

Maar het is hoe dan ook een extra aandachtspunt dat erbij komt bij dvcs-en. Wat ze niet minder geschikt maakt, maar het vergt wel even wat meer planning vooraf.

[Verwijderd]

Meer planning? Of gewoon andere planning?

[kenneth]

Meer. Operationele data opeens gedistribueerd hebben staan (ie. niet alleen meer op servers) is niet echt een gebruikelijke situatie.

[Sardaukar]

Woy schreef op donderdag 12 februari 2009 @ 16:08:
[...]

Ik reageerder op

[...]

"Wel eens" vat ik op als: "Niet ongebruikelijk", maar laten we het daar maar niet meer over hebben. Levert toch niks constructiefs op

Mee eens - zand erover

[Sardaukar]

kenneth schreef op vrijdag 13 februari 2009 @ 00:19:
Meer. Operationele data opeens gedistribueerd hebben staan (ie. niet alleen meer op servers) is niet echt een gebruikelijke situatie.

Je moet ook snappen dat Git een specifiek probleem van Linus oplost - het is daarom primair gebouwd voor de open-source ontwikkeling van Linux.

In dat opzicht speelt bovenstaand punt minder. Als maintainer van de tree zorg je wel dat jij jouw spullen goed bijhoudt, maar als iemand anders dat wil clonen en een eigen repo wil bijhouden heb je daar geen beheerszorgen over. Het valt buiten jouw verantwoordelijkheid.

Dit uiteraard in tegenstelling tot een bedrijfssituatie.

Overigens zie ik nog te vaak dat programmeurs die werken met een VCS te lang in hun eigen working copy werken en niet beseffen dat hun eigen lokale harddisk niet in een back-up strategy meeloopt...

[ Voor 1% gewijzigd door Sardaukar op 13-02-2009 08:56 . Reden: typo ]

[Sardaukar]

drm schreef op donderdag 12 februari 2009 @ 23:05:

offtopic:
* drm vraagt zich in de tussentijd af of deze discussie zich zo langzamerhand naast de klassiekers "MS of open source" of "Linux of FreeBSD" of "Firefox of Opera" mag scharen

Valt wel mee toch? Zolang mensen maar versiecontrol gebruiken in welke vorm dan ook (nou ja, met een uitzondering voor SourceSafe )

[Sardaukar]

roy-t schreef op donderdag 12 februari 2009 @ 23:58:

offtopic:
O.o Opera en Kate!

Ik zie zelf eigenlijk maar vrij weinig voordelen van de distributed aanpak, vooral het mergen lijkt me ontiegelijk iritant als je alle veranderingen mee wilt nemen.

User A werkt in repository van User B en voegt aan File C regels D toe.
User E werkt ook in de repository van User B en voegt aan File C regels F toe. (tot zover nog redelijk te mergen

Nu voegt User G in de repository van User A aan File C regels H toe.
En voegt User I in de repository van User E aan File C regels J toe.l

Hoe zorg je er nu voor dat je als User X, de meest recente versie hebt van File C met zowel de wijzigingen van A, E, G en I.

-G, I en B moeten onlin zijn. (in dit geval mogelijk maar in systemen met 25+ man waar iedereen telkens wisselt van het gebruik van andermans repo moeten haast wel iedereen online zijn om echt alle veranderingen te krijgen)
-Stel G heeft een bug gefixed en een extra methode toegevoegd in de gepulde repro van A, en de code die I toegevoegd heeft aan E's repro staat daardoor op de verkeerde plek (bug fix in andere methode). GIT+ moet dan taal-aware zijn of zoeken naar bit patronen om uit-tevogelen hoe een merge tussen G, I, B eruit gaat zijn, maar wie zegt er niet dat dat bitpatroon er toevallig is (als het te kort is kan dit snel) en dat de eigenlijk code waarna de wijzingen van I moeten komen verwijdered is?

-Ook bij stukken die 2x bewerkt zijn lijkt me dit helemaal een hel, omdat het in dit geval niet 1 of 2x is zoals meestal bij een centrale repro, of niet bij een checkout repro, kan dit door de vele branches en verschillende repro's echt ontzettend de hand uitloop.

Het door jouw beschreven scenario zou op deze wijze inderdaad niet werken (of op zijn minst erg lastig zijn). Daarom wordt er in de praktijk altijd wel tegen een repository aan gewerkt die men beschouwd als de laatste versie.

Wijzigingen levert men dan op door:

• Te pushen naar die repository
• Losse patches te versturen naar de maintainer van die repo met de vraag om ze te mergen
• Je eigen repo te publiceren en te vragen aan de maintainer van de andere repo of hij jouw changes wil binnenhalen.

Er wordt hier gezegd dat dit hetzelfde is als centraal werken, maar het is eigenlijk veel flexibeler. Je kunt namelijk onderling bepalen welke repo nu eigenlijk leidend is. De leidende repo is nu eigenlijk het gevolg van een afspraak.

Stel dat je als programmeur bijvoorbeeld bezig bent voor een feature. Om de een of andere reden wil je hulptroepen inschakelen om die feature sneller af te krijgen (of beter, of meer features, whatever). Je kunt in dat geval afspraken maken dat JOUW lokale repo leidend wordt en dat je teamleden van jouw repo gaan klonen. Wijzigingen leveren zij dan aan jou op en ze weten dat ze de laatste wijzigingen via jouw repo binnen kunnen halen.

Als over een week de situatie anders is, kun je kiezen voor een andere structuur. In dit opzicht is het veel flexibeler.

[ Voor 0% gewijzigd door Sardaukar op 13-02-2009 10:10 . Reden: typo ]

[djc]

kenneth schreef op donderdag 12 februari 2009 @ 23:59:
Dat over backups van lokale changes. Dat vind ik toch wel een belangrijk aandachtspunt, juist omdat het allemaal zo verspreid is. En het idee van een duidelijke 'laatste versie' vind ik (in een bedrijfsomgeving) wel belangrijk.

Vind ik nogal onzinnig; in een CVCS kan je ook een working dir vol changes hebben die niet wordt gebackupt. In een DVCS stuur je alle changes die af zijn natuurlijk gewoon naar een centrale server (en dat hoeft dan nog niet eens een integration tree te zijn, kan ook een persoonlijke branch zijn). En omdat je commits met een DVCS vaak kleiner worden, heb je feitelijk juist meer backups.

[kenneth]

Nouja, onzinnig is het niet. Bij CVCS heb je commit en je bent klaar. Bij DVCS heb je commit + backup/push.
Het is geen ramp of een showstopper ofzo, maar het is wel iets wat je in de gaten moet houden.

[Sardaukar]

Bij CVCS hoef je alleen maar commit te doen om er zeker van te zijn dat je meedraait in de back-up? Ja, maar dat geldt alleen als de back-up strategy voor die server ook goed geregeld is.

Als je bij een DCVS al je publieke repo's op 1 server zit en die meeneemt in de back-up strategy heb je hetzelfde resultaat als die centrale VCS met back-up.

DVCS met publieke repo's op meerdere servers is in een ander punt dan weer beter: geen single point of failure . Wel weer meer beheer, ja.

Kortom: back-ups spelen altijd een issue en moeten per situatie (VCS of DVCS) goed worden geregeld.

[MBV]

kenneth schreef op vrijdag 13 februari 2009 @ 10:53:
Nouja, onzinnig is het niet. Bij CVCS heb je commit en je bent klaar. Bij DVCS heb je commit + backup/push.
Het is geen ramp of een showstopper ofzo, maar het is wel iets wat je in de gaten moet houden.

commit + push bij dezelfde werkwijze, maar wat ik begrijp van de DVCS gebruikers is een commit iets wat je elke 5 minuten doet (vergelijkbaar met CTRL+S in eclipse*), en een push vergelijkbaar met een commit.

*) in eclipse worden alle tussenliggende versies ook opgeslagen tot je een commit doet.

[Sardaukar]

MBV schreef op vrijdag 13 februari 2009 @ 14:08:
[...]

commit + push bij dezelfde werkwijze, maar wat ik begrijp van de DVCS gebruikers is een commit iets wat je elke 5 minuten doet (vergelijkbaar met CTRL+S in eclipse*), en een push vergelijkbaar met een commit.

Een commit is een change doorvoeren in je eigen repository. Een push is al je changes (of een specifieke) doorvoeren in een andere repository.

Wat ik zelf merk is dat mijn commits inderdaad vrij kort op elkaar volgen. Een commit staat bij mij gelijk aan 1 klein taakje wat ik afgerond heb.

Een nog niet belicht voordeel van Git: de index (ook wel staging-area genoemd). Hiermee kun je kiezen welke bestanden je bij je volgende commit wilt doorvoeren.

Een praktisch voorbeeld: voor een hobby-project wilde ik een feature toevoegen. Tijdens het ontwikkelen van deze feature merkte ik dat het handig was dat ik mijn unittesten daar ook voor ging refactoren (andere naam/plaats). Ik heb de boel gerefactored en ik zit nu met twee dingen in mijn working copy, namelijk de gewijzigde unittests en een feature die nog niet af is.

Ik voeg alleen de bestanden van de unittesten toe aan de index. Vervolgens ga ik committen.

Nu zijn mijn wijzigingen van de unittest als losse commit binnengekomen terwijl ik vrolijk verder kan werken aan mijn feature.

Let wel: dit beschouw ik zelf ook als behoorlijk power-user niveau, maar het geeft wel de kracht van Git aan (Mercurial kent dit bijvoorbeeld niet).

[ Voor 4% gewijzigd door Sardaukar op 13-02-2009 14:31 ]

[Mr_Light]

Uiteindelijk word in CVCS en in DVCS de zelfde merge gedaan, bij DVCS bestaat deze merge alleen vaker uit kleinere stapjes. En worden merges dus ook automatisch door meerdere mensen ge-checked voordat hij in een van de 'centrale' punten komt.

Een junior developer kan dus eerst naar een senior pushen.
Wat betreft online zijn: je kan ook gewoon naar een server pushen

[ppl]

roy-t schreef op donderdag 12 februari 2009 @ 23:58:
<quote>here’s not really a “latest version”. If there’s no central location, you don’t immediately know whether to see Sue, Joe or Eve for the latest version. Again, a central location helps clarify what the latest “stable” release is.

There aren’t really revision numbers. Every repo has its own revision numbers depending on the changes. Instead, people refer to change numbers: Pardon me, do you have change fa33e7b? (Remember, the id is an ugly guid). Thankfully, you can tag releases with meaningful names.</quote>

Een CVS (centraal of distributed) is alleen maar bedoeld om versiebeheer van files te doen, meer niet. Dit voorbeeld gaat daar dan ook niet over, het gaat over een procedureel probleem. Aan dit soort voorbeelden kun je dan weer heel mooi zien dat het techneuten zijn die het geschreven hebben, de oplossing wordt namelijk op technisch vlak gezocht. Voor dit soort dingen hebben ze projectmanagement bedacht (in dit geval is dat release beheer), een CVS (centraal of distributed) is hier echt niet voor bedoeld (hooguit een middel om je releases te kunnen beheren, waar je het in kunt stoppen). Je moet gewoon vooraf afspreken wat je doet, hoe je met bepaalde dingen omgaat, hoe je die tag releases named en dat soort zaken. Dat is dus niet alleen beperkt tot hoe je bepaalde code schrijft of wat de huisstijl van bepaalde documenten is.

[frickY]

We hebben op het webdev-kantoor eindelijk SVN uitgerolt, maar lopen nu helaas tegen een performance probleem aan. Ik ben benieuwd of hier ervaringen en mogelijke oplossingen voor bekend zijn.

Onze ontwikkelwebserver staat in een extern datacenter. Het lokale bedrijfsnetwerk heeft een VPN naar die machine, waardoor iedereen de benodigde mappen via netwerk shares kan benaderen.
Nu hebben wij SVN op die server geinstalleerd en een repository aangemaakt. We hebben workingcopy's ingesteld voor alle developers en Apache geconfigureerd zodat hier gebruik van gemaakt kan worden.

Het probleem is echter dat een checkout enorm lang duurt.
Commandline geef ik lokaal een checkout commando in de vorm van "svn co svn://devserver/project/Trunk/ P:\project".
P:\ is een samba-mount naar mijn workingcopy op diezelfde server als waar SVN draait.

Hierbij zal mijn SVN client dus alle files uit de repository downloaden, en vervolgens via de samba-share weer uploaden naar diezelfde server in mijn workingcopy. Dat duurt een minuut of 20 voor een redelijk klein project

Een checkout naar een lokale vaste schijf gaat wel acceptabel snel, maar het is ongewenst inl okale WAMP omgevingen te gaan ontwikkelen. Het is een eis dat de workingcopy's en de repositories op de externe ontwikkelserver blijven (ivm SLA's, backups, etc etc).

Zijn er praktische manieren om de bestanden niet eerst naar een client te downloaden welke ze via samba weer terug upload, maar gewoon opdrachten op de server uitvoert?
We zouden allemaal een SSH-connectie naar de server kunnen openhouden in bijv. putty en checkout's steeds remote doen, maar dat werkt ook niet handig.\

Ik heb met de tool ExpanDrive clientside een netwerkmount over SSH naar de server gemaakt, om uit te sluiten dat Samba de vertragende factor is. Dat had geen effect.
Ook heb ik alle combinaties van uit huis geprobeerd via de externe interface van de server, dus volledig buiten VPN om, maar ook dat geen effect. VPN en Samba zijn dus niet de vertragende factoren. Het lijkt echt in het simultaan lezen en schrijven via een client van de server te zijn.

[ Voor 12% gewijzigd door frickY op 12-03-2009 22:46 ]

[Creepy]

Ik snap niet dat je lokaal een SVN client draait die op een remote share een working copy moet gaan gebruiken. Zo blijf je up en downloaden en dat is traag ja. Je upload waarschijnlijk over iets van een ADSL lijn en dat schiet niet op nee.

Wat is er op tegen om de working copy lokaal te hebben staan? Ik moet er niet aan denken dat ik alle sourcefiles alleen remote heb staan. Scheelt enorm in access tijd van de files om maar niet te spreken over extra compilatie tijd (hier gebruiken we java). Vervolgens kan je lokaal ontwikkelen en hoef je alleen nog maar je changes te commiten (=uploaden).

Iederen devver kan toch prima z'n eigen working copy lokaal houden? Dat hoeft toch niet elke keer gebackupped te worden e.d.? Gewoon ervoor zorgen dat er van de centrale repository een backup gemaakt wordt. Met een SVN hook kan je er dan voor zorgen dat na elke commit van een devver er automatisch een svn update of zelfs een nieuwe checkout op de ontwikkelserver wordt uitgevoerd.

[user109731]

@frickY: vreemde setup, lokale working directory is wel het minste wat ik als developer zou verwachten, is volgens mij altijd sneller...

Anyway, je kunt SVN ook file-based gebruiken. Dus je maakt de repository aan op P:\, checkout kan dan met file:///P:/... Je moet alleen zorgen dat je geen Berkeley DB (maar FSFS) als database formaat gebruikt op een share, dat kan corruptie geven. Zie hier voor meer info.

edit: maar eigenlijk eens met Creepy, het blijft onhandig en altijd trager dan lokaal.

[ Voor 8% gewijzigd door user109731 op 12-03-2009 23:44 ]

[MBV]

@Jan: heb je daar een bron van? Op mijn stageadres wordt nu gesuggereerd om iedereen met een SVN repo op de fileshare te laten werken, en ik zou dat probleem graag onderbouwd zien.

Mijn onderbuik zegt trouwens ook dat het beter is om een SVN server te gebruiken, maar daar heb ik niet echt een rationalisering voor.

[frickY]

Creepy schreef op donderdag 12 maart 2009 @ 23:33:
Ik snap niet dat je lokaal een SVN client draait die op een remote share een working copy moet gaan gebruiken. Zo blijf je up en downloaden en dat is traag ja. Je upload waarschijnlijk over iets van een ADSL lijn en dat schiet niet op nee.

Goede samenvatting van het probleem

Wat is er op tegen om de working copy lokaal te hebben staan? Ik moet er niet aan denken dat ik alle sourcefiles alleen remote heb staan. Scheelt enorm in access tijd van de files om maar niet te spreken over extra compilatie tijd (hier gebruiken we java). Vervolgens kan je lokaal ontwikkelen en hoef je alleen nog maar je changes te commiten (=uploaden).

Volledig mee eens, maar kan er helaas niets aan doen.
Vorig jaar is besloten dat alle interne servers worden uitgefaseerd en alles in het datacenter komt te staan.
Redenen hiervoor zijn onder andere geweest dat intern niet voldoende kennis en discipline is om de servers te beheren en te backuppen. Aan die keus is helaas niets meer te doen, ik zit vast aan de externe ontwikkelserver.

@JanDM
Ook filebased hebben we het zelfde probleem. Die files zullen ook extern staan.


Eigenlijk zoek ik iets als een remote shell voor SVN. Of ik zou mijn Zend Studio niet naar "svn.exe" moeten laten wijzen maar naar "tunnel.bat". In die bat-file zou ik dan iets kunnen doen als

code:

putty -h devserver < "svn %1"

Zend denkt dan tegen een lokale client te lullen maar ondertussen wordt alles op de server zelf geregeld. Voor de server zijn het gewoon local files en is alles dus snel.
Maar is hier een kant-en-klare oplossing voor? In dit voorbeeld zou het pad naar de workingcopy bijv al niet kloppen (S:\project\ ipv /wwwroot/workingcopy/fricky/project).

[ Voor 3% gewijzigd door frickY op 13-03-2009 10:14 ]

[user109731]

MBV schreef op vrijdag 13 maart 2009 @ 00:05:
@Jan: heb je daar een bron van? Op mijn stageadres wordt nu gesuggereerd om iedereen met een SVN repo op de fileshare te laten werken, en ik zou dat probleem graag onderbouwd zien.

De Subversion FAQ. En uit het SVN-Book:

[30] Berkeley DB requires that the underlying filesystem implement strict POSIX locking semantics, and more importantly, the ability to map files directly into process memory.

If you attempt to use Berkeley DB on a noncompliant remote filesystem, the results are unpredictable—you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted. You should strongly consider using the FSFS data store for repositories that need to live on a network share.

Ik zie nu dat FSFS de default is sinds Subversion 1.2, dan is bovenstaande niet zo relevant...

[MBV]

frickY schreef op vrijdag 13 maart 2009 @ 09:26:
Eigenlijk zoek ik iets als een remote shell voor SVN. Of ik zou mijn Zend Studio niet naar "svn.exe" moeten laten wijzen maar naar "tunnel.bat". In die bat-file zou ik dan iets kunnen doen als

code:

putty -h devserver < "svn %1"

Zend denkt dan tegen een lokale client te lullen maar ondertussen wordt alles op de server zelf geregeld. Voor de server zijn het gewoon local files en is alles dus snel.
Maar is hier een kant-en-klare oplossing voor? Is dit voorbeeld zou het pad naar de workingcopy bijv al niet kloppen (S:\project\ ipv /wwwroot/workingcopy/project).

Dat was ook de kant waar ik in gedachten al heen ging. Kant-en-klaar zal je niet vinden, je zal de dingen door sed o.i.d. heen moeten gooien om \ in / te veranderen en idd de paden te veranderen. andere oplossing: remote werken?
Trouwens: /wwwroot/workingcopy? Werken jullie allemaal op 1 checkout? Dan kan je dus niet eens bijhouden wie wat heeft ingecheckt

JanDM schreef op vrijdag 13 maart 2009 @ 09:43:
Ik zie nu dat FSFS de default is sinds Subversion 1.2, dan is bovenstaande niet zo relevant...

Met FSFS maakt het dus niet uit? Ok, bedankt

[frickY]

MBV schreef op vrijdag 13 maart 2009 @ 09:53:
Trouwens: /wwwroot/workingcopy? Werken jullie allemaal op 1 checkout? Dan kan je dus niet eens bijhouden wie wat heeft ingecheckt

Nee, ieder krijgt een eigen workingcopy. Heb het voor de volledigheid maar aangepast.
Maar probeerde mijn posts eenvoudig te houden, het is al complex genoeg

Disclaimer: Deze en andere posts zijn een versimpelde weergave van de werkelijkheid

[Creepy]

Je kan prima een WAMP install lokaal draaien en daar op devven. Pas als wat je moet gaan doen werkt, check je de boel in en kan je geautomatiseerd de sources op de ontwikkelserver laten updaten. Ik zie niet in waarom dat niet zou kunnen? Het lijkt mij niet zo heel erg nuttig om elke working copy van elke devver te laten backuppen. Zorgt gewoon dat iedereen z'n werk netjes incheckt en de laat SVN en de ontwikkelserver zelf dan wel backuppen.

[ Voor 30% gewijzigd door Creepy op 13-03-2009 10:35 ]

[MBV]

frickY schreef op vrijdag 13 maart 2009 @ 10:13:
[...]

Nee, ieder krijgt een eigen workingcopy. Heb het voor de volledigheid maar aangepast.
Maar probeerde mijn posts eenvoudig te houden, het is al complex genoeg

Disclaimer: Deze en andere posts zijn een versimpelde weergave van de werkelijkheid

Soms hoop je dat iemand de versimpelde weergave geeft, maar ben je heel erg bang dat het niet zo is. Ken je dat niet? Dan moet je eens www.thedailywtf.com doorlezen

[frickY]

Onze situatie komt vrijwel overeen met die uit dit topic Samba share 'hangt' regelmatig sinds TortoiseSVN install.

Alleen hebben wij nog niet eens Turtoise geinstalleerd en dus nog geen last van trage statuschecks. In dat topic wordt helaas met geen woord gesproken over trage checkouts of commits.
Wat wel verschilt is dat hun server in een 100Mbit LAN hangt, onze server staat in het WAN waar wij een 20Mbit verbinding mee hebben, maar in de bandbreedte lijkt de bottleneck sowieso niet te zitten.
Heb alle test ook vanuit huis uitgevoerd over een simpel kabelabbonement maar met dezelfde resultaten.

Creepy schreef op vrijdag 13 maart 2009 @ 10:19:
Je kan prima een WAMP install lokaal draaien en daar op devven.

Technisch wel ja, maar volgens het huidige bedrijfsbeleid is dat uitgesloten.

[ Voor 16% gewijzigd door frickY op 13-03-2009 11:51 ]

[MBV]

Zou het geen betere snelheid kunnen geven om apache te gebruiken, i.p.v. de interne webserver van SVN?

En anders moet je de problemen met de huidige opstelling uitleggen aan je management, uitleggen hoeveel tijd=geld je ermee kwijt bent, wat de kosten ervan zijn, en dat dus de policy veranderd moet worden. Als je de policy verandert in lokaal WAMP-servers draaien, en aan het eind van de dag een verplichte checkin doen (op eventueel een branch), dan is de veiligheid van de gegevens net zo goed gewaarborgd.

[Verwijderd]

frickY schreef op vrijdag 13 maart 2009 @ 11:46:
Technisch wel ja, maar volgens het huidige bedrijfsbeleid is dat uitgesloten.

Misschien is het nuttig na te denken over het volgende: wat is hier de oorzaak van de problemen, de techniek of het bedrijfsbeleid? Een technisch probleem zal een in essentie verkeerd bedrijfsbeleid nooit op kunnen lossen. Als dat beleid het probleem is zou ik adviseren te proberen dat te wijzigen c.q. gewijzigd te krijgen.

Als dat echt onmogelijk is kun je proberen een technische work around werkend te krijgen, maar echt geweldig zal dat nooit worden.

[Creepy]

frickY schreef op vrijdag 13 maart 2009 @ 11:46:
Technisch wel ja, maar volgens het huidige bedrijfsbeleid is dat uitgesloten.

Dus het huidige bedrijsbeleid zorgt ervoor dat jullie gewoon niet optimaal kunnen werken. Je bent en extra tijd kwijt (o.a. met dit topic) om een niet optimale situatie beter te krijgen en je normale werk kost je ook nog eens extra tijd. No offence maar ik denk dat het tijd wordt om toch eens te praten over dat beleid. De redenen die je nu noemt (backups etc) zijn wat mij betreft geen reden voor het niet lokaal mogen ontwikkelen. Je kan prima lokaal ontwikkelen en toch op een centrale server de laatste updates te hebben staan die ook nog eens worden gebackupped.

Vasthouden aan het ontwikkelen met meerdere ontwikkelaar over een 30Mbit lijn blijft gewoon niet optimaal. Dit kost je altijd snelheid.

Edit: wat Wezz ook zegt dus

offtopic:
* Creepy mept MBV

[ Voor 3% gewijzigd door Creepy op 14-03-2009 09:32 ]

[MBV]

Creepy schreef op vrijdag 13 maart 2009 @ 22:08:

Edit: wat Wezz ook zegt dus

offtopic:
psst, kijk eens naar die post boven wezz

[djc]

Ass-backwards setup... Ik zou als ik jou was gewoon op de server gaan werken als je WC daar ook moet staan. (Dus via bijvoorbeeld SSH shell of VNC.) Een scriptje zoals je beschrijft kan vast ook wel, maar zul je wel moeten schrijven, jullie opzet is veel te niet-standaard.

[ Voor 44% gewijzigd door djc op 14-03-2009 23:58 ]

[frickY]

Inmiddels heeft een collega een VBS-scriptje geschreven en deze als SVN-client ingesteld in Zend Studio.
Het scriptje verzamelt de argumenten waarmee hij wordt aangeroepen, replaced wat paden, en gebruikt plink (a command-line interface to the PuTTY back ends) om het commando via SSH op de ontwikkelserver uit te voeren. Lijkt uitstekend te werken, alleen blijft de cscript-engine af en toe een paar seconde hangen.
Even een paar dagen mee testen en dan eens vervangen met een C-programmatje.

Alleen jammer dat een dergelijke oplossing niet werkt voor tools zoals SmartSVN.

[user109731]

* kick *

Joel Spolsky heeft een interessante post over DVCS vs. VCS. Hij is ook de auteur van hginit.com, een Mercurial tutorial. Leuk om te zien dat deze systemen populair zijn geworden in de open-source wereld, en nu ook steeds meer bedrijven overstappen

[djc]

Sinds naast BitBucket ook Google Code en CodePlex en Fog Creek (het bedrijf van Spolsky) Mercurial zijn gaan aanbieden zie je inderdaad steeds meer developers met DVCS in aanraking komen. Spolsky heeft natuurlijk een enorm publiek, en met zijn StackOverflow DevDays heeft hij Mercurial ook al onder de aandacht gebracht.

[YopY]

JanDM schreef op maandag 29 maart 2010 @ 10:40:
Hij is ook de auteur van hginit.com, een Mercurial tutorial.

Even kijken.

Gelijk in het eerste hoofdstuk doet hij al iets foudt:

Now, here’s how Subversion works:

When you check new code in, everybody else gets it.
Since all new code that you write has bugs, you have a choice.

* You can check in buggy code and drive everyone else crazy, or
* You can avoid checking it in until it’s fully debugged.

Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.

Euh. Nooit van een feature branch gehoord? Gewoon je 'work in progress' in een branch pleuren, ontwikkelen tot het klaar is, mergen met trunk. Subversion 101, en volgens mij weet hij hier ook wel van, maar laat hij het gewoon terzijde omdat hij Mercurial positiever neer wil zetten.

Verder lijkt het in zijn intro (paar paragrafen verderop) dat lokale Mercurial repositories eigenlijk vergelijkbaar zijn met 'persoonlijke' feature development branches in een klassieke SVN. Of zie ik het verkeerd?

bla bla changesets mergen vs revision mergen

Dat probleem had ik ook met het proberen te mergen van een grote branch, maar dat is op te lossen door alle revisions in de branch één voor één te mergen met de trunk - ofwel, alle 'changesets' apart mergen, ipv de veranderingen aan het end van een branch in één keer proberen te mergen. Waren maar 20 (ofzo) revisies, maar toch. Is natuurlijk wel makkelijk dat Mercurial dit in één keer automagisch doet. Moet je dan ook evt. conflicts per changeset oplossen?

Mja. Op basis van de eerste twee hoofdstukken lijkt Mercurial op het eerste gezicht SVN met verbeteringen te zijn, makkelijker branchen / mergen. Console client is nog steeds niet m'n ding, echter .

[user109731]

YopY schreef op maandag 29 maart 2010 @ 16:13:
Euh. Nooit van een feature branch gehoord?

Daar zegt hij dit over:

“The trouble with distributed version control is that it makes it too easy to branch,” I said, “and branching always causes problems.” Turns out this was wrong, too. I was on a streak. Branching causes problems in Subversion because Subversion doesn’t store enough information to make merging work. In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

YopY schreef op maandag 29 maart 2010 @ 16:13:
Dat probleem had ik ook met het proberen te mergen van een grote branch, maar dat is op te lossen door alle revisions in de branch één voor één te mergen met de trunk - ofwel, alle 'changesets' apart mergen, ipv de veranderingen aan het end van een branch in één keer proberen te mergen.

Grappig dat je dat noemt, doet me denken aan dit stukje:

What should have been a five minute process ended up with six programmers around a single computer working for two weeks trying to manually reapply every single bug fix from the stable build back into the development build.

YopY schreef op maandag 29 maart 2010 @ 16:13:
Mja. Op basis van de eerste twee hoofdstukken lijkt Mercurial op het eerste gezicht SVN met verbeteringen te zijn, makkelijker branchen / mergen. Console client is nog steeds niet m'n ding, echter .

Er is TortoiseHG, en IDE-support is steeds beter.

Mercurial is niet de heilige graal uiteraard, wijzig je allebei dezelfde regel dan moet je natuurlijk mergen. Maar mergen hoeft wel minder vaak, stel je voegt een regel toe in een functie, en een collega verplaatst diezelfde functie, dan kan Mercurial dat volgens mij automatisch mergen. Bovendien kun je mergen wanneer je wil (iedere SVN gebruiker weet wel wat er gebeurt als je svn update doet en er zijn conflicten ).

Natuurlijk, Joel is vast biased en voor veel projecten is SVN imho prima te gebruiken, maar ik zie wel de volgende voordelen: 1) snel (lokaal) branchen, committen etc. 2) geen .svn/.hg directories in subdirectories 3) .hgignore ipv properties 4) ingebouwde webserver, hg serve.

[LauPro]

Wat volgens mij veel mensen in dit draadje vergeten is dat SC-systemen een middel zijn en geen doel. En wat bij versiebeheer ook van belang is dat je historie hebt, omschakelen van versiebeheersysteem zorgt er in de regelmaat voor dat je je historie weggooit. Hier heb ik nog niemand iets over horen zeggen. Op dit moment lijkt mij git het meest ideaal, zelf gebruik ik nog veel Subversion. Eerlijk gezegd is mijn ontwikkelcyclus vrij lineair en de architectuur dusdanig dat er weinig conflicten kunnen optreden. En op het moment dat een architectuuraanpassing noodzakelijk is dan kan je altijd nog een lock instellen - of zoals sommigen suggeren alles eerst in een git repos mergen .

De ellende met git vind ik dat het nog vrij veel in ontwikkeling is en je dus maar nooit weet welke conversies je nog te wachten staat.

Verder vind ik meneer Joel Spolsky een beetje uit de hoogte blaten. Hij heeft blijkbaar een oplossing gevonden die voor hem werkt maar dat wil niet zeggen dat het interessant is voor andere organisaties.

Overigens heeft de consequentie van What should have been a five minute process imo weinig met het source control system te maken. Als je goede unit tests hebt en die ook consequent doet na elke commit (of om de dag) dan spoor je eventuele inconsistenties zeer snel op.

Dus @JanDM ga niet het gat in je ontwikkelproces verhalen op het source control system.

[user109731]

LauPro schreef op maandag 29 maart 2010 @ 19:19:
En wat bij versiebeheer ook van belang is dat je historie hebt, omschakelen van versiebeheersysteem zorgt er in de regelmaat voor dat je je historie weggooit. Hier heb ik nog niemand iets over horen zeggen.

De meeste projecten zijn probleemloos te importeren, kijk maar naar de grotere open-source projecten. Ik weet toevallig van Wine (SVN -> Git) en Mozilla (CVS -> Mercurial) dat die de volledige historie nog hebben.

Overigens heeft de consequentie van What should have been a five minute process imo weinig met het source control system te maken. Als je goede unit tests hebt en die ook consequent doet na elke commit (of om de dag) dan spoor je eventuele inconsistenties zeer snel op.

Dus @JanDM ga niet het gat in je ontwikkelproces verhalen op het source control system.

Welk gat in mijn ontwikkelproces? Het gaat erom dat branchen en mergen in deze systemen beter gaat dan in SVN, unit tests zijn alleen handig om te controleren of het mergen goed is gegaan. Het mergen zelf wordt er niet (veel) eenvoudiger door. Het verschil is, even heel simpel gezegd en uitzonderingen daargelaten, automatisch mergen + unit tests draaien, of handmatig mergen + unit tests draaien.

[ Voor 5% gewijzigd door user109731 op 29-03-2010 20:10 ]

[H!GHGuY]

Ik merk dat veel mensen enkel en alleen de technische voor-/nadelen opsommen van DVCS/CVCS.

Er zijn ook redenen waarom een DVCS niet per se onbeheerbaar hoeft te zijn:
- Je kan code ownership afdwingen door (net zoals in de linux kernel) subsystem maintainers te hebben die dan naar de centrale/latest tree pushen. Dit wil zeggen dat iemand met kennis over het betreffende stuk de boel moet reviewen voor hij alles naar de master tree pusht.
- Daarbij kun je op elk niveau in de hierarchie een verschillend testing niveau voorschrijven (UVT, DVT, SVT).
- git kan zonder veel moeite verschillende pulls/merges (van verschillende trees) uit elkaar houden via de gemeenschappelijke ancestor (je hebt beiden ooit van de master tree gecloned). Dus dat is een non-argument.

Je VCS kan een 'enabler' zijn van het proces dat je wil gebruiken. Bijvoorbeeld:
Wij gebruiken nu CVS met 2 branching strategieën afh van het project (stabilizing branch of development branch). Daar zijn een hele hoop scripts bovenop geschreven om een reeks problemen op te lossen:
- een project bestaat uit tal van checkouts van verschillende locaties op de CVS server
- sommige van die code is mee gebrancht, andere is dan weer gelabeled
- enz..
We hebben bvb ook een script om een listing te maken van welke commits moeten gereviewed worden.
Daarnaast bevat elke module een history file (met enkel $log$) die we telkens apart moeten committen.

We zijn nu op zoek naar een vervanger en zien toch enkele voordelen aan zowel SVN als git:
- SVN: extra commit parameters (bvb reviewed by, bugtracker #, ...)
- SVN: continuous builds, eventueel via hooks getriggered.
- betere merge tracking
- git: sharen van development code via pulls/merges
- git: veelvuldig branchen/mergen per feature/bugfix/...
om er maar enkele op te noemen.

Er zijn ook wel wat problemen:
svn:externals lost het verschil tussen code in de repo en code in de checkout slechts gedeeltelijk op. Het git equivalent is nog minder goed op dat vlak. (Anderzijds kun je de vraag stellen of we onze code niet moeten herschikken)
De learning curve van git is nou niet bepaald aantrekkelijk. Hoeveel van die fantastische features en meerwaarde van DVCS zullen ook daadwerkelijk dagelijks gebruikt worden (tov SVN<->CVS)?
Alles moet ook binnen je nightly-build-systeem passen natuurlijk (alhoewel dat eerder een kwestie is van je nightly-build-systeem mee aan te passen).
Er kruipt allemaal werk (=geld) in (onderzoek, scripts aanpassen/weggooien, de overstap zelf, aanleren van nieuwe commando's en mogelijkheden, documentatie aanpassen, ...) waarvan je slechts moeilijk de ROI kunt bepalen.

[ValHallASW]

H!GHGuY schreef op maandag 29 maart 2010 @ 20:03:
- SVN: extra commit parameters (bvb reviewed by, bugtracker #, ...)
- SVN: continuous builds, eventueel via hooks getriggered.

De commit parameters zijn toch gewoon log messages met bepaalde info in een bepaald formaat? Zo niet, dan kan je het daarmee implementeren in git. Continuous builds zijn ook bij git prima mogelijk (maar vereisen iets meer denkwerk over wanneer de build getriggerd moet worden;

De learning curve van git is nou niet bepaald aantrekkelijk.

Mwa, die learning curve vind ik eigenlijk nogal meevallen. Het is vooral wennen omdat je SVN al gewend bent. Toegegeven, dat maakt overstappen van SVN naar git wel minder interessant :-)

Alles moet ook binnen je nightly-build-systeem passen natuurlijk (alhoewel dat eerder een kwestie is van je nightly-build-systeem mee aan te passen).

code:

git reset --hard && make nightly

Er kruipt allemaal werk (=geld) in (onderzoek, scripts aanpassen/weggooien, de overstap zelf, aanleren van nieuwe commando's en mogelijkheden, documentatie aanpassen, ...) waarvan je slechts moeilijk de ROI kunt bepalen.

Dat is inderdaad het moeilijke. Het voordeel van git is overigens wel dat je gemakkelijk kunt interfacen met een svn-server - dat betekent dus dat je lokaal met git werkt maar dat je wel de centrale svn-repository hebt.

In het algemeen zou ik zeggen: laat developers lekker werken met de tools waar ze zich prettig bij voelen. Dat is ook wat Joel Spolsky meldt: 'ja, onze devvers waren opeens overgestapt naar Hg, 't is niet alsof ze het management daarover informeren'.

[.oisyn]

JanDM schreef op maandag 29 maart 2010 @ 17:03:
[...]

Daar zegt hij dit over:

[...]


[...]

Grappig dat je dat noemt, doet me denken aan dit stukje:

[...]


[...]

Er is TortoiseHG, en IDE-support is steeds beter.

Wat meneer Joel laat zien is dat hij overduidelijk niet genoeg ervaring heeft met verschillende source control paketten. Het gelul over moeilijk mergen snap ik voor geen meter, maar ik heb CVS/SVN dan ook amper gebruikt. Echter is een branch mergen met Perforce een eitje, wat overduidelijk geen DVCS is. Het ligt dus puur en alleen aan de tool, en niet aan het paradigma. Waar hij zegt dat DVCS beter is dan VCS bedoelt hij eigenlijk gewoon dat Mercurial beter is dan SVN. And that's it. Het hele DVCS vs VCS verhaal is irrelevant.

[LauPro]

JanDM schreef op maandag 29 maart 2010 @ 20:00:
De meeste projecten zijn probleemloos te importeren, kijk maar naar de grotere open-source projecten. Ik weet toevallig van Wine (SVN -> Git) en Mozilla (CVS -> Mercurial) dat die de volledige historie nog hebben.

Op open-source-vlak geloof ik het wel maar het gaat mij dan juist om closed-source repositories naar open-source daar het in de bovenstaande discussie vooral over de omslag van bestaande systemen gaat.

Welk gat in mijn ontwikkelproces? Het gaat erom dat branchen en mergen in deze systemen beter gaat dan in SVN, unit tests zijn alleen handig om te controleren of het mergen goed is gegaan. Het mergen zelf wordt er niet (veel) eenvoudiger door. Het verschil is, even heel simpel gezegd en uitzonderingen daargelaten, automatisch mergen + unit tests draaien, of handmatig mergen + unit tests draaien.

Ik snap niet wat je precies probeert te zeggen, er zit een hoop redundantie in de bovenstaande zinnen. Mijn stelling is dat samenvoegen van broncode altijd vervelend is mits de architectuur hier niet goed voor is geschikt. En niet alleen de architectuur maar ook de taakverdeling heeft hiermee te maken.

In een project zitten bijvoorbeeld gedeelde softwarebibliotheken. Beter zou zijn als maar een paar mensen hieraan werken zodat de wijzigingen beheersbaar blijven. Tevens is het bij de Linux kernel zo dat veel wijzigingssets over vele bestanden gaan als het een API-wijziging betreft. Dit gedrag komt door verschillende factoren o.a. omdat een (of dé) kernel een vrij uniek concept is waar eigenlijk niemand nog over uit is wat de beste architectuur is (zeker bij Linux ).

Dus door in je ontwikkelproces slimmere keuzes te maken heb je uiteindelijk minder conflicten tijdens het samenvoegen.

ValHallASW schreef op maandag 29 maart 2010 @ 22:51:
De commit parameters zijn toch gewoon log messages met bepaalde info in een bepaald formaat? Zo niet, dan kan je het daarmee implementeren in git. Continuous builds zijn ook bij git prima mogelijk (maar vereisen iets meer denkwerk over wanneer de build getriggerd moet worden;

Wat er waarschijnlijk wordt bedoeld is dat in verband met het decentrale aspect je niet (gemakkelijk) kan kruisrefereren naar changesets uit andere git repositories.

Dat is inderdaad het moeilijke. Het voordeel van git is overigens wel dat je gemakkelijk kunt interfacen met een svn-server - dat betekent dus dat je lokaal met git werkt maar dat je wel de centrale svn-repository hebt.

Dit is dus de genoemde lokale git-merge-struc .

Dat is ook wat Joel Spolsky meldt: 'ja, onze devvers waren opeens overgestapt naar Hg, 't is niet alsof ze het management daarover informeren'.

Ik vraag mij dan af wat hij dan eigenlijk wel te vertellen heeft. Met dit soort geblaat komen we nergens.

[djc]

LauPro schreef op maandag 29 maart 2010 @ 19:19:
De ellende met git vind ik dat het nog vrij veel in ontwikkeling is en je dus maar nooit weet welke conversies je nog te wachten staat.

Conversies? Ik denk niet dat dat een issue wordt.

JanDM schreef op maandag 29 maart 2010 @ 20:00:
De meeste projecten zijn probleemloos te importeren, kijk maar naar de grotere open-source projecten. Ik weet toevallig van Wine (SVN -> Git) en Mozilla (CVS -> Mercurial) dat die de volledige historie nog hebben.

Mozilla is niet zo'n goed voorbeeld, want die hebben wel een tijdje parallel CVS en Mercurial bijgehouden, maar hebben niet alle geschiedenis meegenomen naar Mercurial. Maar het klopt wel dat je conversies vaak goed kan doen, ik ben hier bijvoorbeeld mee bezig voor Python en Jython. Sommige SVN-repos zijn wel zo'n teringzooi dat het wat ingewikkeld is...

H!GHGuY schreef op maandag 29 maart 2010 @ 20:03:
- Je kan code ownership afdwingen door (net zoals in de linux kernel) subsystem maintainers te hebben die dan naar de centrale/latest tree pushen. Dit wil zeggen dat iemand met kennis over het betreffende stuk de boel moet reviewen voor hij alles naar de master tree pusht.

Dit is inderdaad een hele goede aanpak, die veel mensen vergeten omdat het niet past bij push-based (CVS, SVN) version control. Pull-based kan betekenen (zoals in monotone verder geformaliseerd is) dat je een duidelijke hierarchie kan hebben van de developers, waar je alleen dingen van mensen pullt die je vertrouwt. Die mensen kunnen weer anderen vertrouwen (in een bepaald gebied), etc. Dit is een van de dingen die Linus goed uitlegt in zijn Google Tech Talk over git.

H!GHGuY schreef op maandag 29 maart 2010 @ 20:03:
svn:externals lost het verschil tussen code in de repo en code in de checkout slechts gedeeltelijk op. Het git equivalent is nog minder goed op dat vlak. (Anderzijds kun je de vraag stellen of we onze code niet moeten herschikken)

Mercurial heeft subrepos, dat wel aardig in de buurt begint te komen van svn:externals. Met als added bonus dat je subrepositories ook uit SVN en (binnenkort) git kunt halen.

H!GHGuY schreef op maandag 29 maart 2010 @ 20:03:
De learning curve van git is nou niet bepaald aantrekkelijk.

Dit is wel een van de belangrijke pluspunten van Mercurial, wat mij betreft (en ook een belangrijke reden dat bijvoorbeeld Fog Creek en CodePlex voor Mercurial kiezen in plaats van git): de UI van git is gewoon kut met peren. Mensen kunnen wel roepen dat het vooral komt omdat je SVN moet ontwennen, maar als je kijkt naar bzr of Mercurial blijkt dat je ook prima DVCS kunt doen met een UI die grotendeels net als SVN functioneert.

En inderdaad, Perforce kon een heleboel dingen beter dan CVS/SVN, maar DVCS heeft zelfs ten opzichte van Perforce nog wel een aantal voordelen (lokale historie is wel echt een stuk beter te ontsluiten dan remote).

[user109731]

LauPro schreef op dinsdag 30 maart 2010 @ 00:59:
[...]
Op open-source-vlak geloof ik het wel maar het gaat mij dan juist om closed-source repositories naar open-source daar het in de bovenstaande discussie vooral over de omslag van bestaande systemen gaat.

Ja, als je een VCS gebruikt dat niet te importeren is in één van de andere systemen heb je een probleem. In de praktijk zie je bij de meeste bedrijven TFS, Perforce of een van de open-source systemen.

Dus door in je ontwikkelproces slimmere keuzes te maken heb je uiteindelijk minder conflicten tijdens het samenvoegen.

Mee eens dat het verdelen van taken het aantal conflicten kan verminderen. Maar dat is niet altijd mogelijk en het lost lang niet alle problemen op, denk aan het mergen van een stable naar een development branch.

[Kalentum]

LauPro schreef op dinsdag 30 maart 2010 @ 00:59:
[...]
Op open-source-vlak geloof ik het wel maar het gaat mij dan juist om closed-source repositories naar open-source daar het in de bovenstaande discussie vooral over de omslag van bestaande systemen gaat.

Wat bedoel je precies met closed source repositories? Closed source SCM of closed source projecten die in een SCM beheerd worden? Voor wat betreft de eerste: er zijn conversietools. Voor wat betreft de tweede: de aard van de licentie van de software heeft geen gevolgen voor je SCM.

En git svn clone <svn repos> gaat retesnel (als je je beperkt tot 1 branche) en is triviaal.

Ik snap niet wat je precies probeert te zeggen, er zit een hoop redundantie in de bovenstaande zinnen. Mijn stelling is dat samenvoegen van broncode altijd vervelend is mits de architectuur hier niet goed voor is geschikt. En niet alleen de architectuur maar ook de taakverdeling heeft hiermee te maken.

Ik werk met Subversion en de trunk is altijd in een releasebare staat. Elke feature is een branche (tenzij hotfix of te triviaal voor een branche). Features worden gereleased als het klaar is, er zit geen planning op. Ik begrijp dat jij lineair ontwikkeld. Dus je begint nooit aan B als A nog niet af is. Echter in de meeste situaties is dat niet gewenst. Ik branche dus veel en merge ook veel. Samenvoegen van broncode is misschien vervelend maar het is ook gewoon onderdeel van het ontwikkelproces. Ik heb geen zin om mijn werkwijze aan te moeten passen aan een SCM.

In een project zitten bijvoorbeeld bedeelde softwarebibliotheken. Beter zou zijn als maar een paar mensen hieraan werken zodat de wijzigingen beheersbaar blijven.

De meeste SCM systemen kunnen deze werkwijze ondersteunen.

Dus door in je ontwikkelproces slimmere keuzes te maken heb je uiteindelijk minder conflicten tijdens het samenvoegen.

Paard achter de wagen? Je richt je werkproces dus in om maar niet te hoeven mergen?

[Olaf van der Spek]

Nadeel van Subversion vind ik dat svnserve geen TLS ondersteunt en de Apache module niet bruikbaar is omdat ik geen Apache draai. Dus gebruik ik nu een SSH port forward, maar dat is ook niet ideaal, aangezien het een system user nodig heeft. Is daar geen oplossing voor?

[ Voor 35% gewijzigd door Olaf van der Spek op 30-03-2010 12:43 ]

[MBV]

in Apache zou je mod_proxy kunnen gebruiken (die alles doorstuurt van een beveiligde naar een onbeveiligde poort), heeft IIS niet zoiets?

[Olaf van der Spek]

Ik gebruik Debian en Lighttpd...
Een HTTP proxy is natuurlijk niet hetzelfde als een port forward.

[pascalw]

Olaf van der Spek schreef op dinsdag 30 maart 2010 @ 13:36:
Ik gebruik Debian en Lighttpd...
Een HTTP proxy is natuurlijk niet hetzelfde als een port forward.

Tegen dit probleem loop ik al heel lang aan, tot dusver ook nog geen oplossing voor kunnen vinden helaas.

[Sardaukar]

LauPro schreef op maandag 29 maart 2010 @ 19:19:
De ellende met git vind ik dat het nog vrij veel in ontwikkeling is en je dus maar nooit weet welke conversies je nog te wachten staat.

De structuur van een Git-repository ligt gewoon vast hoor. Je hoeft dus niet bang te zijn dat je repo na een nieuwe release van Git ineens niet meer zou werken.

Het is met name de omliggende tooling waaraan nog veel gesleuteld wordt. Iets wat ik persoonlijk prima vind: als je de mailinglijst volgt zie je gewoon heel veel kleine verbeteringen binnenkomen. Git wordt er alleen maar beter van.

[Olaf van der Spek]

PWSoft schreef op dinsdag 30 maart 2010 @ 17:03:
Tegen dit probleem loop ik al heel lang aan, tot dusver ook nog geen oplossing voor kunnen vinden helaas.

Hmm, nu ik erover nadenk, is het misschien handiger om svnserve niet public te laten luisteren en forwarding door of SSH of een web server/proxy te laten doen. Dan heb je weer een open poort minder.

[pascalw]

Svnserve ondersteund ook SASL authenticatie en encryptie zag ik net, meteen even getest en werkt prima.

[Olaf van der Spek]

PWSoft schreef op woensdag 31 maart 2010 @ 22:39:
Svnserve ondersteund ook SASL authenticatie en encryptie zag ik net, meteen even getest en werkt prima.

Wat voor encryptie?
Alleen voor de authenticatie of voor al het verkeer?

[pascalw]

"Data encryptie" volgens de documentatie, dus ik ga er vanuit dat al het verkeer encrypted wordt.

[ Voor 14% gewijzigd door pascalw op 01-04-2010 07:38 ]

[Soultaker]

Ik meen dat je svnserve via ssh kunt aanspreken; je repository url wordt dan [url]svn+ssh://example.com/repository[/]. Authenticatie gaat dan ook via ssh, dus je hebt dan zowel authenticatie als encryptie vrij goed geregeld.

[H!GHGuY]

ValHallASW schreef op maandag 29 maart 2010 @ 22:51:
[...]
De commit parameters zijn toch gewoon log messages met bepaalde info in een bepaald formaat? Zo niet, dan kan je het daarmee implementeren in git. Continuous builds zijn ook bij git prima mogelijk (maar vereisen iets meer denkwerk over wanneer de build getriggerd moet worden;

Het gaat over properties. Je zou in git idd kunnen werken met fixed-format strings zoals er nu de git-reserved strings "Signed-off by" enz zijn.

[...]
Mwa, die learning curve vind ik eigenlijk nogal meevallen. Het is vooral wennen omdat je SVN al gewend bent. Toegegeven, dat maakt overstappen van SVN naar git wel minder interessant :-)

Het gaat em niet zo over het concept, eerder over de enorm uitgebreide command list.
Doe op linux maar eens een "man git", je bent er een tijdje zoet mee.

[pascalw]

Soultaker schreef op donderdag 01 april 2010 @ 12:30:
Ik meen dat je svnserve via ssh kunt aanspreken; je repository url wordt dan [url]svn+ssh://example.com/repository[/]. Authenticatie gaat dan ook via ssh, dus je hebt dan zowel authenticatie als encryptie vrij goed geregeld.

Klopt, maar dan moet je iedereen die je toegang wilt geven dus een system account geven, ssh keys uitwisselen etc.