Versiebeheer tooling

[Arethusa]

Er kwam iets voorbij over Sourcesafe in dit topic?. Ik heb nog wel een puntje waar ik me aan erger. Ik draai Sourcesafe op zowel mijn pc als op de laptop. Mijn pc schijf bestaat uit een partitie en mijn laptop uit 2.
Op de 1e partitie van mijn laptop draait Windows Vista (welke ik nooit gebruik) en op de tweede draait Windows XP

Nu kun je dus binnen Sourcesafe instellen welke applicatie je wilt gebruiken om je bestanden te bekijken/bewerken. Nu staat op mijn pc en laptop Notepad++ ingesteld. Op de pc staat dit programma op de C: schijf en op mijn laptop op de D:.

Ik ben dan ook niet erg gecharmeerd van het feit dat Sourcesafe meent dat deze gegevens per account moeten worden opgeslagen. Ik moet nu altijd wanneer ik een bestand wil openen op de laptop het pad naar Notepad++ aanpassen dat hij naar de D: schijf verwijst ipv de C:.

Wat heeft het uberhaupt voor nut om dit per account te bewaren? Nou ja, over een tijdje stappen we over naar SVN en daar heb je deze eigenaardigneden niet.

[Haan]

Arethusa schreef op donderdag 21 oktober 2010 @ 14:18:
<vss rant>

Iedereen is het er al lang over eens dat VSS een k*t product is hoor

[Arethusa]

Ja, terecht ook maar ik had dit puntje nog niet voorbij zien komen en wilde ook mijn gal even spuien

[ Voor 48% gewijzigd door Arethusa op 21-10-2010 14:54 ]

[BM]

Arethusa schreef op donderdag 21 oktober 2010 @ 14:18:
Nou ja, over een tijdje stappen we over naar SVN en daar heb je deze eigenaardigneden niet.

Nee, maar daar krijg je een berg andere ellende voor terug

Hier op werk word SVN gebruikt, maar ben er totaal niet van gecharmeerd. Zal vast (mede) aan de inrichting liggen, maar ik verlang op dit moment terug naar mijn vorige opdracht, waar VSS werd gebruikt. Dat werkt wel gewoon.

[Sebazzz]

SVN + bugs in de implementatie van NTFS in Windows 7

[AtleX]

BM schreef op donderdag 21 oktober 2010 @ 14:54:
[...]

Nee, maar daar krijg je een berg andere ellende voor terug

Hier op werk word SVN gebruikt, maar ben er totaal niet van gecharmeerd. Zal vast (mede) aan de inrichting liggen, maar ik verlang op dit moment terug naar mijn vorige opdracht, waar VSS werd gebruikt. Dat werkt wel gewoon.

Wat gaat er fout dan?

Sebazzz schreef op donderdag 21 oktober 2010 @ 14:58:
SVN + bugs in de implementatie van NTFS in Windows 7

Die bug heeft helemaal geen relatie met SVN hoor.

[Sebazzz]

AtleX schreef op donderdag 21 oktober 2010 @ 15:03:
[...]

Die bug heeft helemaal geen relatie met SVN hoor.

SVN is wel de enige toepassing waarbij ik (en dus waarschijnlijk ook anderen) er last van hebt.

[AtleX]

Ik kon het reproduceren met een aantal setups en TPP2 triggert 'm ook.

[Sebazzz]

En checkdisk wordt gedraaid bij de eerstvolgende reboot.

Er is wel een gelimiteerde patch beschikbaar: You receive an error message that states the file system is broken in Windows 7 or in Windows Server 2008 R2

[FragFrog]

BM schreef op donderdag 21 oktober 2010 @ 14:54:
Hier op werk word SVN gebruikt, maar ben er totaal niet van gecharmeerd. Zal vast (mede) aan de inrichting liggen,

Of hoe je het gebruikt

Zo heb ik ook een collega die continue overhoop ligt met SVN. Tja, als je de .svn bestanden mee gaat comitten (hoe'ie dat voor elkaar gekregen heeft is me nog steeds een raadsel) of continue probeert eerst te comitten voor je update, of handmatig in twee branches dezelfde wijziging doet en dan vreemd gaat kijken als je merge conflicten krijgt.. heb je het ook wel een klein beetje aan jezelf te danken

[roy-t]

Sebazzz schreef op donderdag 21 oktober 2010 @ 15:22:
[...]

SVN is wel de enige toepassing waarbij ik (en dus waarschijnlijk ook anderen) er last van hebt.

Maar dat is al een hele oude toch? IK had het een jaar geleden altijd als ik VisualSVN server had gedraait, maar ondertussen heb ik er nooit meer last van. Volgens mij is dat al lang gepatched in Windows 7.

[Sebazzz]

Ik en klasgenoten heb er nog wel af en toe last van. De enige optie is de virusscanner en indexer configureren om niet in de repository te komen. Overigens staat de patch pas voor Service Pack 1 geplanned.

[BM]

AtleX schreef op donderdag 21 oktober 2010 @ 15:03:
[...]

Wat gaat er fout dan?

Als je een bestand verwijderd (of map) die al bestond, en deze weer aanmaakt voor je commit, en dan probeerd te commiten, komt ie met foutmeldingen aanzetten (vraag me ff niet welke). Verwijder --> commit --> aanmaken --> commit en het werkt prima. Casing van files is niet aan te passen.
Dat zijn zo 2 dingen die me te binnen schieten. Heeft misschien nog nieteens zoveel met SVN te maken, maar toch

FragFrog schreef op donderdag 21 oktober 2010 @ 16:27:
[...]

Of hoe je het gebruikt

Zo heb ik ook een collega die continue overhoop ligt met SVN. Tja, als je de .svn bestanden mee gaat comitten (hoe'ie dat voor elkaar gekregen heeft is me nog steeds een raadsel) of continue probeert eerst te comitten voor je update, of handmatig in twee branches dezelfde wijziging doet en dan vreemd gaat kijken als je merge conflicten krijgt.. heb je het ook wel een klein beetje aan jezelf te danken

Zal ongetwijfeld ook (gedeeltelijk) aan mij liggen Branching gebruiken we hier (nog) niet, en meeste projecten werkt maar 1 persoon aan, dus das ook niet zo'n punt.

Zou graag over gaan naar TFS (ben wel van mening dat je met VS maar beste ook een MS versiebeheer tool kunt gebruiken), maar daar is geloof ik geen budget voor

[ Voor 3% gewijzigd door BM op 21-10-2010 18:22 ]

[Sebazzz]

TFS is wel wat meer dan versiebeheer natuurlijk

[alienfruit]

Laatst nog gehad ik wilde wat conflicts solven en Eclipse/Subversive ging eerst reverten en dan committen. Maar goed Eclipse crashde tijdens de revert actie. Weg mijn wijzigingen . Natuurlijk een paar dagen voor de deadline.

[FragFrog]

BM schreef op donderdag 21 oktober 2010 @ 18:21:
Als je een bestand verwijderd (of map) die al bestond, en deze weer aanmaakt voor je commit, en dan probeerd te commiten, komt ie met foutmeldingen aanzetten (vraag me ff niet welke).

Duh. Als jij de .svn files verwijdert en dat probeert te comitten (wat je effectief aan het doen bent) gaat het fout ja - je maakt dan je lokale repository representatie stuk. Als je eerst update voor je die verwijderde map weer probeert te comitten zul je zien dat je SVN client netjes aangeeft dat de map weer onder versiebeheer wordt gebracht. Daarom: eerst updaten, dan comitten. Bespaart je een berg problemen

SVN is een prima pakket, maar er zitten een paar quirks in - als je dat eenmaal weet valt er goed mee om te gaan in mijn opinie

GiT daarentegen..

[Anoniem: 164019]

Ik vind Mercurial toch een stuk fijner dan SVN. Ik zou ook Git boven SVN verkiezen, alleen al omdat mijn internetverbinding soms onprettig doet en ik toch m'n werk wil committen om het gewoon even "af te sluiten". Ook extensions waarmee je makkelijk proefbranches kunt maken kunnen soms heel erg helpen.

Zijn er nog goede redenen voor het gebruik van gecentraliseerde RCSs, of is het het gebrek aan goede gedecentraliseerde systemen? Mercurial bevalt me namelijk best wel

[Sardaukar]

FragFrog schreef op donderdag 21 oktober 2010 @ 20:40:
[...]
SVN is een prima pakket, maar er zitten een paar quirks in - als je dat eenmaal weet valt er goed mee om te gaan in mijn opinie

GiT daarentegen..

Ligt aan de gebruiker

Toegegeven, hoge leercurve. Maar tot nu toe heb ik een aantal mensen begeleid met de overgang naar Git en niemand wil nu meer terug naar TFS.

[Matis]

Wij gebruiken op de zaak CVS. De reden hiervoor is/zijn de RCS bestanden die een bepaald bestand tijdens een bepaalde revisie vertegenwoordigt. Geen geklooi met relationele databases.

Daarnaast is het rollback-en al een paar keer handig gebleken

[Kalentum]

Matis schreef op donderdag 21 oktober 2010 @ 20:55:
Wij gebruiken op de zaak CVS. De reden hiervoor is/zijn de RCS bestanden die een bepaald bestand tijdens een bepaalde revisie vertegenwoordigt. Geen geklooi met relationele databases.

Wat bedoel je daarmee? Ik heb al lang geen CVS meer gezien, maar ik zie de relatie met een database niet?

[FragFrog]

Sardaukar schreef op donderdag 21 oktober 2010 @ 20:54:
Ligt aan de gebruiker

Toegegeven, hoge leercurve.

Eensch en eensch. Ik wil simpel kunnen branchen, mergen, comitten en updaten - source-control is om mij te helpen sneler te developen, ik ben er niet om de source-control te gaan lopen doorgronden. De grafische clients die ik ervoor heb gebruikt zijn verre van logisch of missen domweg opties (al is tortoiseGiT nog een aardige poging, dat wel) dus zit ik noodzakelijkerwijs maar te klieren met de commandline tools die zo mogelijk nog minder intuitief zijn maar tenminste wel alles kunnen. Mind you, ik ben er nog steeds niet achter hoe ik 1 commit van een andere, externe repository kan mergen met m'n lokale checkout

Nee, dan liever de paar quirks en traagheid van SVN, zeker in combinatie met TortoiseSVN toch wel erg spiffy - gebruik het tegenwoordig zelfs voor word documenten, tot mijn grote verbazing kun je die zelfs netjes diffen

[ Voor 12% gewijzigd door FragFrog op 21-10-2010 21:06 ]

[Sebazzz]

FragFrog schreef op donderdag 21 oktober 2010 @ 20:40:
[...]

SVN is een prima pakket, maar er zitten een paar quirks in - als je dat eenmaal weet valt er goed mee om te gaan in mijn opinie

FragFrog schreef op donderdag 21 oktober 2010 @ 20:40:
[...]

MySQL is een prima pakket, maar er zitten een paar quirks in - als je dat eenmaal weet valt er goed mee om te gaan in mijn opinie

FragFrog schreef op donderdag 21 oktober 2010 @ 20:40:
[...]

PHP is een prima pakket, maar er zitten een paar quirks in - als je dat eenmaal weet valt er goed mee om te gaan in mijn opinie

[FragFrog]

Sebazzz schreef op donderdag 21 oktober 2010 @ 21:08:

jaja, duidelijk

_{Al durf ik toch wel te beweren dat het aantal quirks in SVN een verdraaid stuk lager ligt dan in, zeg, PHP}

[ Voor 30% gewijzigd door FragFrog op 21-10-2010 21:14 ]

[Avalaxy]

Tja, de flexibiliteit van Git is inderdaad waar de tool keihard op afgemaakt of aangeprezen wordt. Ik ben er zelf van overtuigd dat Git superieur is aan andere version control systemen, maar dat komt vooral omdat ik er gewoon een boek over ben gaan lezen, want het is inderdaad moeilijk te begrijpen zonder fatsoenlijke GUI Onder linux schijn je overigens wel goede GUI's te hebben, maar daar heb ik geen ervaring mee

[Voutloos]

rutgerw schreef op donderdag 21 oktober 2010 @ 21:05:
[...]
Wat bedoel je daarmee? Ik heb al lang geen CVS meer gezien, maar ik zie de relatie met een database niet?

Dat is het excuus om SVN ingewikkelder te noemen, maar die kan ten eerste ook file based werken, en ten tweede boeit het geen reet want er zijn prima tools. SVN meer voordelen dan nadelen tov CVS, terwijl de werkwijze niet echt verschilt (itt tot distributed implementaties als GIT & co), dus de keuze tussen die 2 moet een no-brainer zijn.

[Sardaukar]

FragFrog schreef op donderdag 21 oktober 2010 @ 21:05:
[...]
Mind you, ik ben er nog steeds niet achter hoe ik 1 commit van een andere, externe repository kan mergen met m'n lokale checkout

Da's het leuke van Git: meerdere wegen naar Rome.

1. Leg in je repository een remote aan naar de tweede repository. Daarna doe je een 'git fetch' om alle objecten van die repository naar binnen te trekken. Gebruik daarna 'git cherry-pick' om de commit te kiezen
2. Gebruik in je tweede repo 'git format-patch' om een patch van de commit te maken. Trek deze daarna binnen in je eerste repository via 'git am' of 'git apply'.

De kracht van Git is juist dat je zo ontzettend flexibel bent.

[Sardaukar]

Avalaxy schreef op donderdag 21 oktober 2010 @ 21:13:
Tja, de flexibiliteit van Git is inderdaad waar de tool keihard op afgemaakt of aangeprezen wordt. Ik ben er zelf van overtuigd dat Git superieur is aan andere version control systemen, maar dat komt vooral omdat ik er gewoon een boek over ben gaan lezen, want het is inderdaad moeilijk te begrijpen zonder fatsoenlijke GUI Onder linux schijn je overigens wel goede GUI's te hebben, maar daar heb ik geen ervaring mee

Ik ben ook een grote fan. Ik gebruik het gewoon onder Windows via een Powershell commandline. Werkt prima en ik heb zelfs wat Powershell scripting die aangeeft op welke branch je zit, wat de status van je index is, etc.

[Kalentum]

Voutloos schreef op donderdag 21 oktober 2010 @ 21:16:
[...]
Dat is het excuus om SVN ingewikkelder te noemen, maar die kan ten eerste ook file based werken, en ten tweede boeit het geen reet want er zijn prima tools. SVN meer voordelen dan nadelen tov CVS, terwijl de werkwijze niet echt verschilt (itt tot distributed implementaties als GIT & co), dus de keuze tussen die 2 moet een no-brainer zijn.

Ah het ging om de backend van Subversion. Dat is voor mij een beetje set and forget.

[Voutloos]

En terecht, want tenzij je echt episch aan het falen bent hoef je er niet aan te komen.

[FragFrog]

Sardaukar schreef op donderdag 21 oktober 2010 @ 21:18:
Da's het leuke van Git: meerdere wegen naar Rome.

1. Leg in je repository een remote aan naar de tweede repository. Daarna doe je een 'git fetch' om alle objecten van die repository naar binnen te trekken. Gebruik daarna 'git cherry-pick' om de commit te kiezen
2. Gebruik in je tweede repo 'git format-patch' om een patch van de commit te maken. Trek deze daarna binnen in je eerste repository via 'git am' of 'git apply'.

De kracht van Git is juist dat je zo ontzettend flexibel bent.

En beide opties betekenen afaik dat ik eerst die volledige externe repo moet binnenhalen, terwijl ik slechts 1 commit ervan wil hebben - ja, zover was ik, het ging mij er juist om slechts die ene commit binnen te halen. Repo is aardig groot, idealiter zou ik patch willen maken van een remote commit, maar dat lijkt niet te kunnen. Of althans, niet gevonden binnen de tien minuten ofzo die ik ervoor over had ernaar te zoeken

[Sardaukar]

FragFrog schreef op donderdag 21 oktober 2010 @ 21:37:
[...]

En beide opties betekenen afaik dat ik eerst die volledige externe repo moet binnenhalen, terwijl ik slechts 1 commit ervan wil hebben - ja, zover was ik, het ging mij er juist om slechts die ene commit binnen te halen. Repo is aardig groot, idealiter zou ik patch willen maken van een remote commit, maar dat lijkt niet te kunnen. Of althans, niet gevonden binnen de tien minuten ofzo die ik ervoor over had ernaar te zoeken

Onzin, met optie 2 maak je alleen een losse patch aan. Daarna trek je alleen maar die patch naar binnen en doe je dus niks met de gehele repo.

Dat aanleggen van die remote is vooral handig als je meerdere changes achter elkaar naar wilt binnentrekken. Ik gebruik hetzelfde principe om via een Powershell script een repository van TFS te converteren naar Git.

Shameless plug:
http://walkingthestack.wo...ository-using-powershell/

[roy-t]

Als we toch weer op de GIT versus SVN bandwagon zitten wil ik ook mijn beklach over GIT wel even doen.

In mijn opinie is een souce control systeem iets wat de ontwikkelaar moet ondersteunen en er voor moet zorgen dat werk niet kwijt raakt, werk netjes georganiseerd blijft en dat fouten ongedaan kunnen maken. Hieraan voldoen SVN en GIT beide prima.

Maar ik durf te stellen dat GIT zo uitgebreid is dat als je met een groep developers werkt er veel fouten worden gemaakt met updaten, mergen, comitten en de iets geavanceerdere functies. Die fouten brengen juist de hoofdtaken van een source control systeem in gevaar.

SVN is ontzettend simpel, helemaal als je zoiets als TortoiseSVN gebruikt.

Je hebt 3 knopjes nodig en af en toe moet bij conflicten kiezen of je je eigen versie of 'hun versie' wilt houden (ok heel heel af en toe heb je de diff/conflict tools nodig).

Checkout
Update
Commit



Bij GIT is er zoveel te doen, en alles kan op meerdere manieren dat het gewoon te onduidelijk is, totdat je er inderdaad een boek over gelezen hebt. Helemaal omdat er geen echt goede tool voor is (onder Windows). Opties doorbladeren en diegene aanklikken die goed lijkt is immers altijd makkelijker dan maar wat intypen. GIT is zonder vragen de superieure software, maar omdat de gebruiker de zwakste schakel is zou ik, als ik zelf de keuze had, altijd voor SVN kiezen.

Ik lees liever nog een boek over mijn core business (programmeren) dan over hoe ik mijn code opsla .


Mocht men het hier mee oneens zijn, dan hoor ik het graag. Maar dan verwijs ik wel even naar het verschil van lengte tussen de gemiddelde SVN en GIT tutorials

[ Voor 5% gewijzigd door roy-t op 22-10-2010 00:24 ]

[Soultaker]

roy-t schreef op vrijdag 22 oktober 2010 @ 00:23:
Checkout      git clone
Update     git pull
Commit     git commit -a && git push

Is toch niet zoveel lastiger? Het laatste zijn twee commando's omdat er onderscheid is tussen committen naar de lokale repository en pushen naar de remote repository. (Eigenlijk is git pull ook een afkorting voor git fetch gevolgd door git merge, wat de andere kant op werkt.)

Natuurlijk, als je echt gedistribueerd gaat werken, met meerdere mensen die verschillende repositories bijhouden, en dan mergen uit verschilende branches, ja, dán wordt het ingewikkeld. Maar dat geldt in principe voor alle gedistribueerde SCMs.

[ Voor 20% gewijzigd door Soultaker op 22-10-2010 00:38 ]

[FragFrog]

Sardaukar schreef op donderdag 21 oktober 2010 @ 21:43:
Onzin, met optie 2 maak je alleen een losse patch aan.

Please do enlighten me: hoe maak ik een losse patch aan als ik dat remote repository niet lokaal heb en ook geen shell toegang oid heb tot dat repository? Ik weet hoe ik een patch trek van een lokale commit, maar van een repository die read-only online staat, hoe doe ik dat?

[Freeaqingme]

Roy; opzich heb je wel een punt git wat moeilijker is, maar als je bedenkt waar 't vandaan komt (een ontevreden Linus), en gewoon bedenkt hoe 't in elkaar zit denk ik dat het wel meevalt qua moeilijksheidsgraad.

Daarnaast heeft svn geen git-stash, en geen github.

Edit: Oh, en 't is niet distributed.

[ Voor 6% gewijzigd door Freeaqingme op 22-10-2010 01:18 ]

[Soultaker]

@FragFrog: met Git heb je altijd de hele repository lokaal, maar het is gezegd dat die vaak kleiner is dan een Subversion working copy van één revisie (!). Ik heb dat zelf niet vergeleken, maar in ieder geval zijn die repositories niet belachelijk groot. Als je alleen een patch wil hebben is het wellicht overkill, dat klopt.

[Anoniem: 59888]

roy-t schreef op vrijdag 22 oktober 2010 @ 00:23:
Mocht men het hier mee oneens zijn, dan hoor ik het graag. Maar dan verwijs ik wel even naar het verschil van lengte tussen de gemiddelde SVN en GIT tutorials

Dat GIT zo moeilijk is dat er fouten onstaan is wat mij betreft onzinnig. Programmeren is ook niet gebruiksvriendelijk, dat wil ook wel eens moeilijk zijn. Als je als programmeur al fouten gaat maken omdat je vcs syteem wat complex is, wat voor code ga je dan schrijven als je een keer met een wat complexere usecase te maken krijgt dan "pietje doet een bestelling bij webshop het gouden ringetje".

In mijn ogen is een programmeur een professional die hard werkt en z'n best doet om goede software te maken. Als GIT de betere tool is haak je niet af omdat het "te moeilijk" is, dan doe je ff wat beter je best en zorg je dat je die tool beheerst. Een programmeur is geen gemiddelde gebruiker, daar mag je heel wat meer van verwachten, niet dat hij/zij afhaakt als er geen wizard is. Gebruiksvriendelijkheid is altijd een pré, maar zou voor een programmeur geen vereiste moeten zijn om met een tool om te kunnen gaan.

[ Voor 5% gewijzigd door Anoniem: 59888 op 22-10-2010 05:03 ]

[alienfruit]

Ik moet zeggen dat ik thuis gewoon Git gebruik en git-svn om met de werk repos te werken. Ik lekker werken... Maar goed command-line is toch fijner dan zo'n Subversive plug-in. Ik vind zelf dat het mergen stukken makkelijker is vergeleken met SVN. Met GIT loopt het stukken minder vaak in de soep voor mij altans.

[ Voor 28% gewijzigd door alienfruit op 22-10-2010 09:09 ]

[Sardaukar]

FragFrog schreef op vrijdag 22 oktober 2010 @ 00:47:
[...]
Please do enlighten me: hoe maak ik een losse patch aan als ik dat remote repository niet lokaal heb en ook geen shell toegang oid heb tot dat repository? Ik weet hoe ik een patch trek van een lokale commit, maar van een repository die read-only online staat, hoe doe ik dat?

Ah, het was me niet duidelijk dat je die andere repository niet lokaal had staan. Maar geen probleem:

1. Clone die remote repository zodat je die lokaal beschikbaar hebt.
2. Gebruik in je nieuwe lokale repository daarop 'git format-patch' voor je specifieke changeset
3. De patch die daaruit komt kun je op je eigen repository toepassen via 'git am' of 'git apply'
4. Verwijder de repository uit stap 1. Heb je niet meer nodig

[Jan_V]

Lees hier veel over GIT, maar niemand over Mercurial.
Ook distributed volgens mij en daar zijn (volgens de site) redelijke tools voor te krijgen om het versiebeheer goed te kunnen ondersteunen, ook binnen Visual Studio.

Niemand hier die het gebruikt, of heeft afgezworen?
Ben aan het overwegen om dit thuis te gaan gebruiken voor m'n projecten.

[Sardaukar]

roy-t schreef op vrijdag 22 oktober 2010 @ 00:23:
Als we toch weer op de GIT versus SVN bandwagon zitten wil ik ook mijn beklach over GIT wel even doen.

Ik lees liever nog een boek over mijn core business (programmeren) dan over hoe ik mijn code opsla .

Mocht men het hier mee oneens zijn, dan hoor ik het graag. Maar dan verwijs ik wel even naar het verschil van lengte tussen de gemiddelde SVN en GIT tutorials

Ik snap wat je wilt zeggen. Ik vergelijk het af en toe wel eens met mensen die zweren bij Notepad++ en andere mensen (waaronder ik) die niet zonder Vim kunnen.

Waarom werk ik zo? Ik wil met de tooling werken die mij de flexibiliteit geeft om mijn werk goed te kunnen doen. Git beschouw ik net zo - ik kan daar dingen mee die ik in TFS / Subversion niet voor elkaar krijg.

Maar ja, die leercurve, nietwaar?

Maar wil dat dan zeggen dat we maar moeten gaan werken volgens het principe van de grootste gemene deler? Ik vind van niet.

En niets staat je tegen om een proces te definieren zodat iedereen weet hoe er verwacht wordt te werken - daarmee verklein je de kans op fouten.

[Sardaukar]

Jan_V schreef op vrijdag 22 oktober 2010 @ 09:17:
Lees hier veel over GIT, maar niemand over Mercurial.
Ook distributed volgens mij en daar zijn (volgens de site) redelijke tools voor te krijgen om het versiebeheer goed te kunnen ondersteunen, ook binnen Visual Studio.

Niemand hier die het gebruikt, of heeft afgezworen?
Ben aan het overwegen om dit thuis te gaan gebruiken voor m'n projecten.

Mercurial is een prima tool die inderdaad onder Windows beter wordt ondersteund dan Git. Ik heb het in het verleden een korte tijd gebruikt en de integratie via Tortoise werkte prima.

Uiteindelijk gekozen voor Git omdat ik daar nog wat flexibiliteit in zie en vind dat er momenteel heel veel momentum in de Git community is.

[bomberboy]

Anoniem: 59888 schreef op vrijdag 22 oktober 2010 @ 05:02:
[...]
Dat GIT zo moeilijk is dat er fouten onstaan is wat mij betreft onzinnig. Programmeren is ook niet gebruiksvriendelijk, dat wil ook wel eens moeilijk zijn. Als je als programmeur al fouten gaat maken omdat je vcs syteem wat complex is, wat voor code ga je dan schrijven als je een keer met een wat complexere usecase te maken krijgt dan "pietje doet een bestelling bij webshop het gouden ringetje".

Een van de "regels" die wij hier gebruiken bij het beoordelen van user-feedback op onze producten is "Als de toepassing fouten die de gebruiker zou maken niet verhindert is dat een fout in het product".
Uiteraard betekent dit niet dat als de gebruiker iets verwijderd maar achteraf beseft dat hij die info toch wou houden de software dat moet aanvoelen op basis van zijn hersengolven ofzo En ja, we zijn er ons ten zeerste van bewust dat dit erg vatbaar is voor interpretatie. Maar eindgebruikers en developers zitten meestal aan de totaal andere kant van het spectrum. Bovenstaande "regel" dient dan ook vooral om beiden meer naar elkaar toe te brengen qua verwachtingen.

In ieder geval ik zie niet in waarom dit in het geval van software voor "professionals" niet zou gelden. Uiteindelijk is een developer ook maar een eind-gebruiker van een version control systeem en moet dus ook niet verwachten dat hij daar meer van weet of mee kan doen dan de basis operaties: "stop het er in, haal het er uit en los conflicten op".

[roy-t]

Anoniem: 59888 schreef op vrijdag 22 oktober 2010 @ 05:02:
[...]

Dat GIT zo moeilijk is dat er fouten onstaan is wat mij betreft onzinnig. Programmeren is ook niet gebruiksvriendelijk, dat wil ook wel eens moeilijk zijn. Als je als programmeur al fouten gaat maken omdat je vcs syteem wat complex is, wat voor code ga je dan schrijven als je een keer met een wat complexere usecase te maken krijgt dan "pietje doet een bestelling bij webshop het gouden ringetje".

Tsja als we er nu hele andere dingen bij gaan halen dan de complexiteit van GIT kan ik natuurlijk op geen enkele manier mijn mening spuien.

Verder ben ik het met je hele post niet eens. Natuurlijk is programmeren moeilijk, maar programmeren in een goede IDE is bijvoorbeeld al best gebruiksvriendelijk.

Zo zie ik GIT vs SVN ook. GIT is het hippe VIM, maar SVN is een IDE die alle saaie (ingewikkelde) taken voor je doet zodat het niet fout kan gaan.*

Software voor programmeurs kan gebruiksvriendelijk zijn en moet in mijn ogen zelfs gebruiksvriendelijk zijn, want met gebruiksvriendelijkere ontwikkeltools houd je meer tijd over voor het echte werk, en dan kun je dus betere (gebruiksvriendelijkere) programmas maken en.. enzovoorts.

We zijn het tijdperk waarbij je zelf het schakelbord in moet stellen nu wel voorbij, daar hebben we immers computers voor .

[X-Lars]

+1 voor Git

Anoniem: 59888 schreef op vrijdag 22 oktober 2010 @ 05:02:
[...]

In mijn ogen is een programmeur een professional die hard werkt en z'n best doet om goede software te maken. Als GIT de betere tool is haak je niet af omdat het "te moeilijk" is, dan doe je ff wat beter je best en zorg je dat je die tool beheerst. Een programmeur is geen gemiddelde gebruiker, daar mag je heel wat meer van verwachten, niet dat hij/zij afhaakt als er geen wizard is. Gebruiksvriendelijkheid is altijd een pré, maar zou voor een programmeur geen vereiste moeten zijn om met een tool om te kunnen gaan.

Daar kan ik op zich wel in mee. Maar daarnaast, als software laagdrempeliger is zullen meer mensen het gebruiken (vraag omhoog) en zal het in principe beter worden (aanbod omhoog) - bijv. door mooie features waar veel vraag naar is. Etcetera. Als alleen een paar Linux kernel programmeurs het gebruiken en er geen GUI voor ontwikkeld wordt, krijgt het geen widespread love.

Ook als professional heb je liever een tool die je niet teveel tijd en energie kost, zodat je meer tijd over hebt voor je core duties. Heck, een GUI kan zelfs fouten voorkomen (bijv. per ongeluk alles tegelijk inchecken) wat de kwaliteit van je eigenlijke werk bevordert.

Ik spreek je dus zeker niet tegen, maar verwachten dat een programmeur elke (betere) tool beheerst is voor mij simpelweg een kwestie van ROI. En het is toch ook wel handig dat bijv. een designer wat kunst of een PM documentatie o.i.d. in kan checken in de tool die de programmeurs uitgekozen hebben.

---

Op de Mac zijn de tools voor Git nog niet van het niveau Versions of Cornerstone, maar ik zie zojuist dat er wel her en der nieuwe GUIs ontstaan (untested):
http://gitbox.pierlis.com/
http://www.gittiapp.com/

Persoonlijk werk ik voornamelijk vanaf de CLI, maar regelmatig is een GUI

[alienfruit]

Bij mij gaat meer dingen fout met SVN dan met GIT

[X-Lars]

alienfruit schreef op vrijdag 22 oktober 2010 @ 11:19:
Bij mij gaat meer dingen fout met SVN dan met GIT

Dat zal niet voor iedereen opgaan, maar ik vind het prachtige samenvatting

[Kalentum]

roy-t schreef op vrijdag 22 oktober 2010 @ 11:08:
Zo zie ik GIT vs SVN ook. GIT is het hippe VIM, maar SVN is een IDE die alle saaie (ingewikkelde) taken voor je doet zodat het niet fout kan gaan.*

Software voor programmeurs kan gebruiksvriendelijk zijn en moet in mijn ogen zelfs gebruiksvriendelijk zijn, want met gebruiksvriendelijkere ontwikkeltools houd je meer tijd over voor het echte werk, en dan kun je dus betere (gebruiksvriendelijkere) programmas maken en.. enzovoorts.

Maar je moet ook naar de functionele kant kijken. git kan dingen die Subversion niet kan. Als je behoefte hebt aan die dingen en vervolgens git niet gaat gebruiken vanwege het ontbreken van een goede GUI dan beperk je jezelf onnodig.

[Sardaukar]

roy-t schreef op vrijdag 22 oktober 2010 @ 11:08:
[...]
Software voor programmeurs kan gebruiksvriendelijk zijn en moet in mijn ogen zelfs gebruiksvriendelijk zijn, want met gebruiksvriendelijkere ontwikkeltools houd je meer tijd over voor het echte werk, en dan kun je dus betere (gebruiksvriendelijkere) programmas maken en.. enzovoorts.

We zijn het tijdperk waarbij je zelf het schakelbord in moet stellen nu wel voorbij, daar hebben we immers computers voor .

Tja, wat gebruikersvriendelijk is voor de een, is de beperking voor de ander. Git kent nu eenmaal een aantal functionaliteiten die ik in Subversion mis.

Kies ik dan voor Subversion wat inderdaad wat makkelijker te bedienen is (omdat het minder kan) en kies ik dus voor de beperking of accepteer ik dat niet en ga ik voor Git (en accepteer de leercurve)?

Overigens heb ik in mijn ervaring de leercurve van Git allang terug verdiend in tijd - ik houd dus ook meer tijd over voor het echte werk

[Janoz]

Ikzelf werk voornamelijk met svn en moet zeggen dat ik er eigenlijk nog nauwelijks problemen mee gehad heb (en de problemen die ik had waren voornamelijk terug te voeren tot een brak ingerichte repository, en dat had ik zelf gedaan ). Er is sowieso al 1 uber reden om svn boven cvs te gebruiken, en dat zijn de atomaire commits. Ik werk op mijn huidige project weer met cvs en af en to mis ik enorm de mogelijkheid om een specifieke commit terug te draaien.

Distributed versiebeheer heb ik zelf nog neit gebruikt, maar ik zie wel degelijk grote voordelen voor grote en verspreide projecten. svn maakt het erg lastig om werkzaamheden halverwege de implementatie over te dragen. Dergelijke halve implementaties wil je vaak helemaal niet op de trunk hebben. Je zult dan met een branch of een patch moeten werken. Uiteraard hoeft branchen helemaal geen probleem te zijn, maar zeker als de bewerking ook weer niet zo groot is het voor mijn gevoel een beetje overdreven om een branch aan te maken. Het geeft nogal een wildgroei aan branches.

[Alex)]

Shelvesets in TFS zijn daar ook handig voor

[Kalentum]

Janoz schreef op vrijdag 22 oktober 2010 @ 14:37:
Uiteraard hoeft branchen helemaal geen probleem te zijn, maar zeker als de bewerking ook weer niet zo groot is het voor mijn gevoel een beetje overdreven om een branch aan te maken. Het geeft nogal een wildgroei aan branches.

Ik vraag me altijd af hoe dat dan in de praktijk gaat. Het komt bij mij best wel eens voor dat feature X nog niet af is en er ondertussen een request komt voor feature Y, met een hogere prioriteit. Als je dan in de trunk werkt, heb je toch kans dat die door elkaar gaan lopen? Hoe vang je dat op?

[djluc]

Dat kom ik hier ook tegen, op dit moment is versiebeheer meer een factor zekerheid waardoor we een keer terugkunnen als we willen of moeten. Het is meer een soort versie-backup eigenlijk maar echt met branches e.d. ontstaat er vaak best wat overhead waardoor we al snel geen voordelen meer ervaren. Al is het natuurlijk schitterend als het wel goed werkt.

[AtleX]

rutgerw schreef op zaterdag 23 oktober 2010 @ 10:52:
[...]


Ik vraag me altijd af hoe dat dan in de praktijk gaat. Het komt bij mij best wel eens voor dat feature X nog niet af is en er ondertussen een request komt voor feature Y, met een hogere prioriteit. Als je dan in de trunk werkt, heb je toch kans dat die door elkaar gaan lopen? Hoe vang je dat op?

Niet, wij hebben vaste releases waarvoor vooraf de scope wordt bepaald. Ad-hoc een wens van een klant inwilligen doen we eigenlijk niet. Je krijgt een wildgroei aan haastig geïmplementeerde klant-specifieke features waar 9 van de 10 keer maar 1 persoon binnen een organisatie een beetje baat bij heeft.

[momania]

Janoz schreef op vrijdag 22 oktober 2010 @ 14:37:
Uiteraard hoeft branchen helemaal geen probleem te zijn, maar zeker als de bewerking ook weer niet zo groot is het voor mijn gevoel een beetje overdreven om een branch aan te maken. Het geeft nogal een wildgroei aan branches.

Wij doen alle nieuwe features eigenlijk zo veel mogelijk in eigen branches. Zo houden we de master als huidige productie release en kunnen we altijd daar vanaf branchen voor hot-fixes. Hebben we een develop branch, waarin waarop we huidige nieuwe features mergen.
En dan met een nieuwe release mergen we of ineens de develop branch in de master, of alleen specifieke nieuwe features/branches. Zo kunnen we altijd nog heel makkelijk beslissen of sommige dingen nou wel of niet mee moeten in de release.
Aangezien het branchen en mergen in git zo enorm makkelijk gaat is de overhead in werk minimaal. SVN kan daar wmb nog een puntje aan zuigen. Daar ging bij mij het mergen bijna nooit in 1 keer goed. Altijd die verdomde merge conflicts. Git heeft me wat dat betreft juist al zo enorm veel tijd, ellende en irritatie bespaard.

[edit]
Oh nog iets, over het makkelijk en moeilijk zijn van een tool, IDE, whatever. Ik neem liever die gast aan die git snapt en in VIM programmeert dan die gast die een IDE nodig heeft of alles wat geen svn heet te moeilijk noemt.

[ Voor 9% gewijzigd door momania op 23-10-2010 11:24 ]

[frickY]

rutgerw schreef op zaterdag 23 oktober 2010 @ 10:52:
Ik vraag me altijd af hoe dat dan in de praktijk gaat. Het komt bij mij best wel eens voor dat feature X nog niet af is en er ondertussen een request komt voor feature Y, met een hogere prioriteit. Als je dan in de trunk werkt, heb je toch kans dat die door elkaar gaan lopen? Hoe vang je dat op?

Dat ligt er een beetje aan of X en Y overlappen.

Als Y in heel andere bestanden is commit ik gewoon alleen die bestanden.
Als er wel overlap is maak ik een nieuwe checkout (of kopieer en revert m'n workingcopy) en ontwikkel daar feature Y. Als dat klaar en gecommit is update ik de workingcopy waar ik met X bezig was en ga verder waar ik gebleven was.
Als het er naar uitziet dat ik wel een poosje met Y bezig ben commit ik de wijzigiingen so far voor X naar een Branche-X. Als Y dan af is ga ik verder in Branch-X, en als dat af is merge ik dat terug en delete de Branch.

Primair werk ik nu in een v2.x branche waarin we bugfixen en features toevoegen voor de 2.1, 2.2, 2.3 etc releases. Bugfixes in reeds gereleasde versies doen we door een Branch te maken vanuit de Release-tag.
Voor een nieuwe versie live gaat clonen we de v2.x naar een v2.4-codefreeze welke de test-omgeving opgaat en die uiteindelijk getagged wordt en live gaat. Bugs gevonden in de test-fase worden gefixed in die codefreeze en terug gemerged naar de v2.x zodra die 2.4 live gaat.
De Trunk gebruiken we momenteel niet. Die komt weer om de hoek kijken als er aan v3 begonnen moet worden.

Ik werk nu ongeveer anderhalf jaar met SVN voor het versiebeheer van de producten bij een web-development bureau. Ik snap nu niet meer hoe ik ooit zonder heb gekund.

[ Voor 23% gewijzigd door frickY op 23-10-2010 11:53 ]

[Freeaqingme]

frickY schreef op zaterdag 23 oktober 2010 @ 11:47:
[...]
Als er wel overlap is maak ik een nieuwe checkout (of kopieer en revert m'n workingcopy) en ontwikkel daar feature Y. Als dat klaar en gecommit is update ik de workingcopy waar ik met X bezig was en ga verder waar ik gebleven was.

Klinkt git-stash toch makkeiljker

[momania]

Freeaqingme schreef op zaterdag 23 oktober 2010 @ 12:21:
[...]


Klinkt git-stash toch makkeiljker

Als je daarvoor git-stash kan gebruiken zijn je features wel heeeeel erg klein, of je commit te weinig

[Janoz]

@Rutgerw & Momania :

Ik zit voornamelijk op nieuwbouw projecten of op projecten met een heel grote oplever cyclus. Dergelijke problemen kom ik dan ook niet tegen. Branchen doe ik vaak bij een wat grotere refactor actie, of wanneer er een stukje POC gedaan moet worden (wanneer het dus nog niet helemaal zeker is of die feature ook op die manier geïmplementeerd gaat worden)

[Kalentum]

Interessant om te lezen in hoeverre het soort project bepaald hoe je omgaat met SCM.

Een release is bij ons gewoon datgene wat is afgerond en door een acceptatietest is gegaan. Die features probeer ik zoveel mogelijk te isoleren. Doorlooptijden van een feature verschillen enorm: kan maanden zijn maar ook een paar uur. Dus het loopt allemaal nogal snel doorelkaar. ik werk in principe zoals Momania beschrijft.

Ik werk met Subversion en merge problemen worden ondervangen door regelmatig de trunk te mergen naar een feature-branche. Hierdoor lopen de branches nooit ver uiteen t.o.v. de trunk.

[Janoz]

rutgerw schreef op zaterdag 23 oktober 2010 @ 15:40:
Interessant om te lezen in hoeverre het soort project bepaald hoe je omgaat met SCM.

Een release is bij ons gewoon datgene wat is afgerond en door een acceptatietest is gegaan. Die features probeer ik zoveel mogelijk te isoleren. Doorlooptijden van een feature verschillen enorm: kan maanden zijn maar ook een paar uur. Dus het loopt allemaal nogal snel doorelkaar. ik werk in principe zoals Momania beschrijft.

Ik werk met Subversion en merge problemen worden ondervangen door regelmatig de trunk te mergen naar een feature-branche. Hierdoor lopen de branches nooit ver uiteen t.o.v. de trunk.

Dat regelmatig mergen is inderdaad wel een vereiste, maar wordt vaak vergeten. (Een andere acceptatie breaker is iemand die denkt iedereen blij te maken door een 'reformat code' over het hele project heen te gooien)

Voor de projecten waaraan ik meegewerkt heb die al in productie waren gold eigenlijk altijd het omgekeerde. Niet de features bepaalden de release, maar de release bepaalde de features. Over het algemeen was er een oplevering elke 3 tot 6 maanden en het moment stond al vast. Een maand tot meerdere maanden voor dat moment was de code freeze al. Alleen in heel uitzonderlijke gevallen kon daar van afgeweken worden (bv wanneer er een acuut security probleem ontdekt was), maar dat heb ik nooit meegemaakt.

[roy-t]

rutgerw schreef op vrijdag 22 oktober 2010 @ 12:25:
[...]


Maar je moet ook naar de functionele kant kijken. git kan dingen die Subversion niet kan. Als je behoefte hebt aan die dingen en vervolgens git niet gaat gebruiken vanwege het ontbreken van een goede GUI dan beperk je jezelf onnodig.

(en @ Saudakar)

Ja dat is inderdaad een andere discussie. Natuurlijk als SVN niet bied wat je nodig hebt zul je wel genoodzaakt zijn om naar iets anders te kijken.

Voor bijvoorbeeld het met veel mensen ontwikkelen van een OpenSource pakket heb je weinig aan SVN. Maar voor bijvoorbeeld het met je 15 collegas werken aan een 'eigen' stuk software zou ik niet weten wat je bij SVN zou missen (het is misschien zelfs een voordeel dan dat SVN centraal werkt).

[TheWickedD]

Hmm, ik ben verrast dat niemand nog bzr (bazaar) heeft genoemt, gebruik het zelf naar veel tevredenheid (hoewel bijna nooit erg geavanceerd). Het is gemaakt door de jongens van Ubuntu, is ook distributed en de verhalen over git klinken best bekent. De combinatie bzr en launchpad werkt erg goed voor mij. Alleen jammer dat er geen integratie met windows producten is (het is natuurlijk nogal een linux ding), maar de commandline draait lekker op windows. Als laatste zijn de plugins ook erg fijn, ookal zijn er nog niet zo veel van. Development draait erg hard, en het werkt ook met SVN en git branches, amongst others. http://bazaar.canonical.com/en/, linkje naar de docs: http://wiki.bazaar.canonical.com/Documentation

Edit:
Blijkt toch een leuke GUI voor te zijn, zelfs op Windows. http://doc.bazaar.canonic.../visual-tour-windows.html Houd de ontwikkelingen niet zo bij...

[ Voor 15% gewijzigd door TheWickedD op 24-10-2010 09:14 . Reden: linkje naar de docs ]

[Sardaukar]

roy-t schreef op zaterdag 23 oktober 2010 @ 16:05:
[...]
Voor bijvoorbeeld het met veel mensen ontwikkelen van een OpenSource pakket heb je weinig aan SVN. Maar voor bijvoorbeeld het met je 15 collegas werken aan een 'eigen' stuk software zou ik niet weten wat je bij SVN zou missen (het is misschien zelfs een voordeel dan dat SVN centraal werkt).

Ik kan wel een voorbeeld geven met betrekking tot TFS (omdat dat het systeem is wat we voor de overstap naar Git gebruikten).

TFS heeft de rare eigenschap dat branches alleen maar teruggemerged kunnen worden naar de parent waar ze vandaan komen*.

Stel dat je een trunk hebt en tegen de tijd dat je een release hebt ga je een release branch maken. Dit levert bij twee releases de situatie op dat je de trunk hebt (parent) en een release 1.0 en een release 2.0 branch (children van de parent). Trunk wordt dan verder gebruikt voor het ontwikkelen van 3.0. Is geen ongewoon scenario.

Nu vind je een bug in de release van 2.0. Dit los je op en wil je eigenlijk ook als een patch beschikbaar stellen voor versie 1.0. In versie 3.0 (de trunk) is het echter geen probleem - laten we zeggen dat het betreffende subsysteem al helemaal gewijzigd is waardoor de bug geen issue is.

Als je in TFS werkt ben je gedwongen om via de parent terug te mergen. Ik moet dus ook eerst mergen naar de trunk met versie 3.0 voordat het door kan naar versie 1.0. Maar versie 3.0 is al geheel anders en mijn merge lijkt dan ook nergens naar. Je wilt het ook niet mergen, want 3.0 is gewoon gewijzigd.

In Git ga ik in branch 2.0 staan en zeg ik simpelweg 'git cherry-pick <changeset>' om die wijziging binnen te trekken. Eventueel merge-conflict oplossen en ik ben klaar.

Dit is slechts één voorbeeld - als er behoefte aan is wil ik er nog wel meer geven.

* Ja, ik weet dat je in TFS met een baseless merge over takken heen kan mergen. Dit is echter hetzelfde als dat ik twee directories zou nemen en deze met Winmerge ga proberen samen te voegen. Je moet elk conflict zelf oplossen. Niet te doen - handmatig de changeset overzetten is vaak nog sneller.

[Sardaukar]

TheWickedD schreef op zondag 24 oktober 2010 @ 09:05:
Hmm, ik ben verrast dat niemand nog bzr (bazaar) heeft genoemt, gebruik het zelf naar veel tevredenheid (hoewel bijna nooit erg geavanceerd).

Reden voor mij om Bazaar niet te gebruiken was dat ik vond/vind dat er een grotere, actievere community achter Git staat.

[roy-t]

Sardaukar schreef op zondag 24 oktober 2010 @ 14:14:
[...]

In Git ga ik in branch 2.0 staan en zeg ik simpelweg 'git cherry-pick <changeset>' om die wijziging binnen te trekken. Eventueel merge-conflict oplossen en ik ben klaar.

Interessant verhaal, lastig probleem voor elk versiebeheer systeem (lijkt me). Nu vraag ik me af hoe GiT dit kan oplossen (met cherry-pick).

Wat is de logica (in je hoofd) om uberhaupt zo'n probleem op te lossen zonder het met de hand te doen / hoe werkt cherrry-pick.

Ik kan namelijk zo in mijn hoofd geen algoritme bedenken wat van de 2.0 branch code verhuist naar de 1.0 branch zonder dat dit heel veel conflicten geeft.

[Sardaukar]

roy-t schreef op zondag 24 oktober 2010 @ 14:46:
[...]
Interessant verhaal, lastig probleem voor elk versiebeheer systeem (lijkt me). Nu vraag ik me af hoe GiT dit kan oplossen (met cherry-pick).

Wat is de logica (in je hoofd) om uberhaupt zo'n probleem op te lossen zonder het met de hand te doen / hoe werkt cherrry-pick.

Ik kan namelijk zo in mijn hoofd geen algoritme bedenken wat van de 2.0 branch code verhuist naar de 1.0 branch zonder dat dit heel veel conflicten geeft.

Eigenlijk is het antwoord eenvoudig. Git is een snapshot based systeem - elke keer als je een commit maakt wordt het verschil tussen deze versie en de laatste commit opgeslagen. Dit gaat over je hele working directory heen - dus niet per bestand.

Zie voor een goede uitleg over snapshots ook deze link. Scroll dan even naar beneden naar 'Snapshots, not changesets'.

Een commit is dus eigenlijk niets anders dan een diff. Deze diff kun je oppakken en apply'en op een andere branch. Omdat Git ook nog weet dat beide branches dezelfde parent hebben, kan er nog wat extra informatie bewaard worden die Git voor het mergen kan gebruiken.

Natuurlijk blijft altijd overeind staan dat het aantal merge-conflicten het kleinst is als:

• de code in beide branches niet ontzettend uit elkaar is gaan lopen
• de changesets zo klein mogelijk zijn.

Omdat Git het aanmoedigt dat je commits zo klein mogelijk zijn, gaat het in de praktijk ook verbazingwekkend vaak goed. En als je dan een keer merge-conflicten hebt, zijn deze heel duidelijk en makkelijk verklaarbaar.

Dit geheel ontslaat je natuurlijk niet van de verantwoordelijkheid dat je - na het apply'en van de changeset - moet kijken of het geheel nog overeind blijft staan.

Maar Git geeft je tenminste nog een fighting chance. Bij TFS ben ik gedwongen om handmatig de patch nogmaals uit te voeren in de andere branch - met alle foutgevoeligheden die daar bij horen.

[Sardaukar]

Als voorbeeld van de flexibiliteit van Git verwijs ik in sessies ook vaak naar dit model.

Lees het eens goed door om te zien hoe hierin verschillende branches samenwerken om tot een duidelijke release-strategie voor software te komen. (Raise hands iedereen als je een release strategie hebt )

Theoretisch zou de workflow die hierin gesteld wordt ook in systemen als TFS en Subversion gedaan kunnen worden. Echter, door de praktische bezwaren van beide systemen (snel branches aanmaken is een drama) zie ik dit niet gebeuren.

[FragFrog]

Sardaukar schreef op zondag 24 oktober 2010 @ 15:44:
(snel branches aanmaken is een drama)

Sinds de nieuwere SVN versies (1.5+) in elk geval is snel branchen en ook mergen een eitje hoor. We maken op werk geregeld een feature-branch, die we even vaak later weer terugmergen naar trunk. Idem voor bugfixes in specifieke branches, die worden zonder moeite gemerged naar de trunk en specifieke release-branches (standaard ondersteunen we altijd twee releases, dus bugfix in de ene moet ook in de ander, en vaak ook in trunk voor toekomstige releases). Vorige week toevallig nog een repository van een aardig oud (5, 6 jaar) product opgeschoond, even drie branches eruit gemikt die al tijden niet meer geupdate werden.

Zeker met TortoiseSVN is branchen in SVN zo simpel als rechtermuisknop bestaand repository -> branch -> naam nieuwe branch opgeven -> eventueel log message -> ok. Gaat mij sneller af dan een CLI openen, naar de directory navigeren en de branch syntax van GiT opzoeken

[Sardaukar]

FragFrog schreef op zondag 24 oktober 2010 @ 16:00:
[...]
Zeker met TortoiseSVN is branchen in SVN zo simpel als rechtermuisknop bestaand repository -> branch -> naam nieuwe branch opgeven -> eventueel log message -> ok. Gaat mij sneller af dan een CLI openen, naar de directory navigeren en de branch syntax van GiT opzoeken

En bij mij werkt 'git checkout -b nieuwefeature' sneller als naar de muis grijpen en bovenstaande stappen uitvoeren . Bovendien zit ik dan meteen al in de nieuwe branch ook.

En Git is daarin nog sneller dan Subversion ook. Bij Subversion zullen eerst alle bestanden in de tree gekopieerd moeten worden naar de nieuwe branch. Bij Git is een branch meer een soort van een view.

Ik heb een working tree waarin ik zit te werken in branch ´master´. Ik maak daarna een branch ´feature´ aan. Er wordt geen nieuwe directory structuur aangemaakt, ik blijf lokaal in mijn zelfde working tree zitten, maar ik zit nu wel geisoleerd in een branch te werken. Als ik nu iets commit wordt dit netjes opgeslagen. Ga ik nu weer naar branch ´master´ wordt alleen het verschil weer teruggezet.

De hele stap waarbij Subversion die branch als directory gaat aanmaken is bij Git dus niet nodig.

Dit klinkt allemaal banaal, maar speed is a feature!. Hoe sneller je tool in dit soort situaties werkt, hoe eerder je er gebruik van zult maken.

[Janoz]

Sardaukar schreef op zondag 24 oktober 2010 @ 16:13:
En bij mij werkt 'git checkout -b nieuwefeature' sneller als naar de muis grijpen en bovenstaande stappen uitvoeren . Bovendien zit ik dan meteen al in de nieuwe branch ook.

Er wordt een GUI voorbeeld gegeven. Op de commandline is het natuurlijk ook maar 1 commando

En Git is daarin nog sneller dan Subversion ook. Bij Subversion zullen eerst alle bestanden in de tree gekopieerd moeten worden naar de nieuwe branch. Bij Git is een branch meer een soort van een view.

We hebben het over svn, niet cvs. Even een quote uit het svn book.

Cheap Copies

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're a Unix user, this is the same concept as a hard-link. From there, the copy is said to be “lazy”. That is, if you commit a change to one file within the copied directory, then only that file changes—the rest of the files continue to exist as links to the original files in the original directory.

This is why you'll often hear Subversion users talk about “cheap copies”. It doesn't matter how large the directory is—it takes a very tiny, constant amount of time to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's website and read about the “bubble up” method in Subversion's design documents.)

Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and space. Make branches as often as you want.

Git heeft zeker zo zijn voordelen en er zijn ook zeker goede redenen om Git boven Subversion te verkiezen, maar laten we ons da wel bij de feiten houden.

De hele stap waarbij Subversion die branch als directory gaat aanmaken is bij Git dus niet nodig.

Dit klinkt allemaal banaal, maar speed is a feature!. Hoe sneller je tool in dit soort situaties werkt, hoe eerder je er gebruik van zult maken.

[Sardaukar]

Janoz schreef op zondag 24 oktober 2010 @ 17:11:
[...]

Er wordt een GUI voorbeeld gegeven. Op de commandline is het natuurlijk ook maar 1 commando


[...]

We hebben het over svn, niet cvs. Even een quote uit het svn book.

[...]


Git heeft zeker zo zijn voordelen en er zijn ook zeker goede redenen om Git boven Subversion te verkiezen, maar laten we ons da wel bij de feiten houden.


[...]

I stand corrected. In mijn ervaring met Subversion stond mij nog bij dat bij het aanmaken van een branch sowieso die informatie van de Subversion-server naar de branch directory werd gekopieerd.

Maar dat was nog voor de 1.5 release, dus ervaring met recente versies heb ik niet.

[ Voor 7% gewijzigd door Sardaukar op 24-10-2010 17:16 ]

[FragFrog]

Sardaukar schreef op zondag 24 oktober 2010 @ 16:13:
En bij mij werkt 'git checkout -b nieuwefeature' sneller als naar de muis grijpen en bovenstaande stappen uitvoeren . Bovendien zit ik dan meteen al in de nieuwe branch ook.

Working copy naar de nieuwe branch switchen is een vinkje in tortoiseSVN, een muisklik meer. Daarnaast is drie muisklikken echt niet significant langzamer dan een commando intikken en kun je als je dat graag wilt ook prima via de CLI branchen. Verder wachten is daarna overbodig: je hebt gelijk een nieuwe branch zonder dat er meuk gekopieerd hoeft te worden, en indien gewenst zit je local copy ook direct daarop.

Andersom, hoe kun jij van een GiT repo eigenlijk zien welke branches er zijn? En dan niet alleen lokale, maar ook de branches die je collega zojuist aangemaakt heeft bijvoorbeeld? Ik ken github, maar hoe doe je dat voor projecten die er niet op zitten?

[ Voor 3% gewijzigd door FragFrog op 24-10-2010 17:32 ]

[Avalaxy]

FragFrog schreef op zondag 24 oktober 2010 @ 17:31:
[...]

Andersom, hoe kun jij van een GiT repo eigenlijk zien welke branches er zijn? En dan niet alleen lokale, maar ook de branches die je collega zojuist aangemaakt heeft bijvoorbeeld? Ik ken github, maar hoe doe je dat voor projecten die er niet op zitten?

git branch -a

[djluc]

Wellicht leuk een zeer relevant om te zien wat een distrubuted systeem voor mogelijkheden biedt. Als je applicaties ontwikkeld in Ruby On Rails kan je gebruik maken van Heroku. Dat is een hostingpartij waarbij je altijd met GIT werkt.

http://docs.heroku.com/git

Middels een programma wat je op je werkstation installeert kan je een nieuwe applicatie aanmaken. Dit wordt automatisch een GIT repository waarbij een target ingesteld wordt. Wat biedt dit voor mogelijkheden:

Je kan simpelweg met een git push production of git push testing de applicatie publiceren. Hierbij wordt je laatste master versie gepubliceerd. Zoals je ziet kan je meerdere omgevingen op de live server hebben (losse applicaties) waardoor je eenvoudig een test live kan zetten en toch de voordelen hebt van lokaal ontwikkelen als je bijvoorbeeld geen internet hebt.

Heb je een nieuw werkstation? Doe een git pull en je hebt de complete applicatie te pakken inclusief history waardoor je meteen verder kunt werken.

[Sardaukar]

FragFrog schreef op zondag 24 oktober 2010 @ 17:31:
[...]

Working copy naar de nieuwe branch switchen is een vinkje in tortoiseSVN, een muisklik meer. Daarnaast is drie muisklikken echt niet significant langzamer dan een commando intikken en kun je als je dat graag wilt ook prima via de CLI branchen. Verder wachten is daarna overbodig: je hebt gelijk een nieuwe branch zonder dat er meuk gekopieerd hoeft te worden, en indien gewenst zit je local copy ook direct daarop.

Andersom, hoe kun jij van een GiT repo eigenlijk zien welke branches er zijn? En dan niet alleen lokale, maar ook de branches die je collega zojuist aangemaakt heeft bijvoorbeeld?

Je kunt in Git zien welke branches je allemaal hebt door middel van het 'git branch' commando. (Het moet niet gekker worden )

Het tweede deel van je vraag kan op meerdere manieren beantwoordt worden en is afhankelijk van hoe je workflow is. Wij gebruiken een centrale Git repository die we als leidend beschouwen (in tegenstelling tot wat sommige mensen denken kan Git ook prima gebruikt worden met een centrale workflow).

Als mijn collega ervoor kiest om een nieuwe branch op die repository te pushen (hij kan namelijk ook lokale branches hebben die ik niet kan zien) kan ik twee dingen doen:

1. Ik gebruik de webinterface die we op die centrale server hebben lopen om te zien welke branch hij heeft aangemaakt (elk teamlid krijgt sowieso een e-mail als iemand wat gepusht heeft naar de centrale repository)
2. Ik heb zelf een remote aangelegd naar de centrale repository. Ik kan de wijzigingen van die remote binnentrekken in mijn eigen repository (git pull). Vervolgens kan ik weer met het 'git branch' commando kijken welke branches er zijn.

Strikt genomen zijn er nog meer mogelijkheden, maar deze zijn het meest voor de hand liggend. Git lijkt wat dat betreft op Perl: There's more than one way to do it. Let wel: hiermee wil ik Perl niet goedpraten

[ Voor 1% gewijzigd door Sardaukar op 24-10-2010 17:47 . Reden: Typo ]

[FragFrog]

Avalaxy schreef op zondag 24 oktober 2010 @ 17:36:
git branch -a

Aah, die kende ik nog niet, thanks!

* FragFrog zat altijd maar op github te kijken

[Sardaukar]

FragFrog schreef op zondag 24 oktober 2010 @ 17:44:
[...]

Aah, die kende ik nog niet, thanks!

* FragFrog zat altijd maar op github te kijken

En ik maar zo'n lang verhaal typen

Maar 'git branch -a' werkt ook prima, inderdaad.

[Anoniem: 59888]

X-Lars schreef op vrijdag 22 oktober 2010 @ 11:15:
+1 voor Git

[lang verhaal]

Om hier nog even op terug te komen. Volgens mij zitten we redelijk op een lijn. Ik stelde het wat kort door de bocht. Waar het mij om ging is dat het inderdaad prettig is als je een gebruiksvriendelijke tool kunt gebruiken. Dat is makkelijker en scheelt tijd. Maar als een tool die wat minder gebruiksvriendelijk is de betere keuze is (aan de hand van de criteria die daar voor opgesteld worden) vind ik het onzin om die tool dan niet te gebruiken omdat hij niet gebruiksvriendelijk is. Mijns inziens mag je in die situatie van een programmeur verlangen dat 'ie dan leert om met die tool om te gaan. Concreet: als git de betere keus is, zou de keuze niet alsnog op SVN moeten vallen omdat de git tools te moeilijk zijn voor de dames en heren programmeurs.

Daar kun je dan allerlei andere dingen bij gaan slepen zoals niet-programmeurs die tools ook moeten gebruiken of het feit dat je tegenwoordig eigenlijk meer van software mag verwachten, maar daar had ik het niet over. Waarvan akte.

offtopic:
Alweer een interessant topic dat uit de coffee-corner is voortgekomen. *bookmarked permanent*

[FragFrog]

Sardaukar schreef op zondag 24 oktober 2010 @ 17:49:
En ik maar zo'n lang verhaal typen

Maar 'git branch -a' werkt ook prima, inderdaad.

For what it's worth: het illustreert wel mooi hoe ik er vanuit ging dat het zou werken, met een centrale repo ergens Dat en het feit dat je college lokale branches kan hebben die jij niet ziet - ik vraag me af of dat nou handig is (zitten bij ons in de repo nog wel eens branches die er eigenlijk vrij snel weer uitgemikt worden) of juist niet (je kan moeilijker zien wat je collega's aan het doen zijn als ze het nog niet gepushed hebben).

Illustreert trouwens ook wel mooi wederom de complexiteit van GiT

Anoniem: 59888 schreef op zondag 24 oktober 2010 @ 17:55:
Concreet: als git de betere keus is, zou de keuze niet alsnog op SVN moeten vallen omdat de git tools te moeilijk zijn voor de dames en heren programmeurs.

Maar waarom zou GiT de betere keuze zijn? Niet om het branchen / mergen in elk geval, dat kan met SVN namelijk ook prima.

[ Voor 21% gewijzigd door FragFrog op 24-10-2010 17:57 ]

[Sardaukar]

FragFrog schreef op zondag 24 oktober 2010 @ 17:56:
[...]

Maar waarom zou GiT de betere keuze zijn? Niet om het branchen / mergen in elk geval, dat kan met SVN namelijk ook prima.

Naast het feit dat ik nog steeds vind dat branchen en mergen in Git makkelijker is dan in Subversion:

• Een commit maken en iets ter integratie aanbieden aan de rest van het team zijn gescheiden dingen geworden. Ik kan in een lokale branch alles doen wat ik wil. Hierin maak ik mijn feature en ga tegen de tijd dat ik deze wil integreren hier eens serieus naar kijken. Vervolgens kan ik de volledige historie van deze branch aanpassen. Ik kan commits samenvoegen, uit elkaar trekken, de volgorde aanpassen, mijn changes opnieuw baseren bovenop de gewijzigde situatie van de master branch. Alles wat ik wil om deze feature netjes ter integratie op te leveren. Deze branch kan ik bovendien ook makkelijk delen met anderen. Zie ook git rebase en git interactive rebase.
• Snelheid. Alle operaties (behalve waarin je communiceert met een remote) werken tegen het filesysteem. Diffen, switchen van branches, historie bekijken en opvragen is allemaal razendsnel.
• Off-line use. Git repo meenemen op een usb-stick. Thuis er aan werken (met volledige historie en alles wat dat met zich meebrengt) en de dag erna op het werk weer netjes integreren is geen enkel probleem.
• Git means never having to say, “you should have”

En nog een hoop andere kleine dingen waarvoor ik nu niet de puf heb om deze te noemen.