SVN naar Git omzetten, hoe daarna verder?

[alwinuzz]

We hebben momenteel een SVN repository waar onze complete programmatuur in zit. Dit is een .Net solution en bestaat uit grofweg 3 delen: core, web en client. Daarnaast nog een paar hulp-projecten en binary dependencies van voor het Nuget tijdperk. Oorspronkelijk 1 ontwikkelaar, nu een team van inmiddels 3 en binnenkort een 4e. De eerste ontwikkelaar neemt dan meer de rol aan van supervisie en reviewen.

We lopen nu tegen een aantal problemen aan:
1. Nieuwe ontwikkelaars zijn vaak extern en van hogerhand mogen we niet alle code in 1x beschikbaar stellen, alleen het deel waar de ontwikkelaar voor is ingehuurd. Wordt nu geregeld met permissies op de SVN server per directory, usergroup en branch. Dit instellen is foutgevoelig, en het is hierdoor lastig nieuwe branches te maken.
2. Mergen is vaak een probleem (bijvoorbeeld conflicts in .csproj bestanden). Branch per feature lukt nu sowieso niet vanwege de permissies van 1. Idealiter zou ik graag per feature een open issue hebben in de issue tracker, daaraan gekoppeld een branch. Wanneer klaar eventueel een code-review en daarna merge met trunk/master.

We zijn nu aan het kijken of het de boel kunnen omzetten naar een aantal kleinere git repositories. Maar omdat wij nauwelijks ervaring hebben met git of andere DVCS, vraag ik om jullie input Gaat verhuizen naar Git ons helpen met bovenstaande knelpunten? Ik denk zelf van wel, maar het leren werken met Git zal ook tijd nodig hebben. Zijn er dingen waar we nog op moeten letten?

Ik heb GitHub uitgeprobeerd, de issue tracker gecombineerd gecombineerd met branches lijkt me handig voor bijv code-reviews. Je kan ook per private repo instellen wie daarin kan werken. Voor preciezere rechtenbeheer is GitLab ook een optie maar ik zie nog niet waarom dat nodig zou zijn.

Ik zoek nog een goede simpele workflow. Feature Branch (https://www.atlassian.com...s/feature-branch-workflow) spreekt mij wel aan. Git Flow lijkt mij overkill. --edit: GitHUB flow is denk ik wat ik zoek-- De workflow die we straks als team gebruiken, moet niet veel moeilijker zijn dan SVN branch/merge en het liefst geen Git shell commando's nodig. Voor SVN gebruiken we nu TortoiseSVN, ik denk dat als we eenmaal met Git bezig zijn we met Atlassian SourceTree en misschien TortoiseGit wel uitkomen.

Verder ben ik wel alvast begonnen met het omzetten om te kijken of dit überhaupt lukt.
1. svn repo clonen naar git repo met svn2git, incl branches, excl tags, de commit history blijft hiermee behouden.
2. git repo opschonen met git filter-branch, o.a. oude binaries eruit.
Tot stap 2 heb ik het werkend.
3. git repo splitsen naar aantal kleinere repo's, weer met git filter-branch.
4. lokale oude branches weg (al lang verwijderd uit SVN) en remotes naar SVN weg.
5. pushen naar bijv. GitHub.

[YakuzA]

Vanwaar de drive naar git? In mijn ervaring kun je met svn vrijwel hetzelfde, opsplitsen naar verschillende svn projecten zal niet de grootste moeite zijn.
Ook issue trackers gekoppeld aan svn bestaan gewoon.

Verder als nieuwe ontwikkelaars niet eens vertrouwd worden, maar dan wel bij een third party als github je sources dumpen klinkt ook wat vreemd.

[Ramon]

Het bedrijf waar ik werk is recent juist van het gebruik van meerdere repositories afgestapt omdat het toch vrij vaak voorkwam dat voor een bepaalde feature in meerdere repo's werk gedaan moest worden en dit was dan gedoe bij deployment. Ik weet natuurlijk niet precies wat jullie bouwen maar als het geen plugins voor een softwarepakket ofzo zijn zou ik toch kijken of je de externen gewoon toegang kan geven tot alle code... lijkt me alles een stuk makkelijker.

Qua git hosting zou ik kijken naar bitbucket > gratis tot 10 users.

Verder is de feature branch workflow een heerlijke workflow waarbij je heel fijn privé aan een feature kan werken zonder andere mensen lastig te vallen. Code reviews zijn goed te doen en het past ook goed bij agile methodes zoals kanban bijv.

[ Voor 25% gewijzigd door Ramon op 16-01-2016 00:52 ]

[_Erikje_]

Wat voor andere toolling gebruiken jullie?

Je kunt ook bitbucket of zelf in je eigen cloud gitlab draaien.

[alwinuzz]

Bedankt voor de reacties. Eerst iets over hosten: of het gratis is of 10 euro per maand maakt ons niet veel uit. Als het maar meerwaarde heeft (gebruikersgemak, weinig onderhoud, bekendheid). Github hebben we enige ervaring mee en tot nu toe werkt het prima. We hebben nog niet met gitlab of bitbucket gewerkt.

YakuzA schreef op zaterdag 16 januari 2016 @ 00:37:
Vanwaar de drive naar git? In mijn ervaring kun je met svn vrijwel hetzelfde, opsplitsen naar verschillende svn projecten zal niet de grootste moeite zijn.
Ook issue trackers gekoppeld aan svn bestaan gewoon.

Verder als nieuwe ontwikkelaars niet eens vertrouwd worden, maar dan wel bij een third party als github je sources dumpen klinkt ook wat vreemd.

SVN opsplitsen kan zeker (in verleden wel eens gedaan). Dan blijven de lastige merges nog steeds bestaan. Issue tracker: we gebruiken nu Trello vooral omdat het eenvoudig werkt en dit gaat best goed, ook al is de integratie niet optimaal. De ingebouwde koppeling tussen issues en commits is wel erg fijn binnen Github. Ik denk dat we als we daarnaar zouden overstappen, we dan Trello zouden afbouwen.

Alternatief voor third party is zelf hosten, dit dan bij moeten houden, voor je het weet loop je een paar security patches achter.

Ramon schreef op zaterdag 16 januari 2016 @ 00:47:
Het bedrijf waar ik werk is recent juist van het gebruik van meerdere repositories afgestapt omdat het toch vrij vaak voorkwam dat voor een bepaalde feature in meerdere repo's werk gedaan moest worden en dit was dan gedoe bij deployment. Ik weet natuurlijk niet precies wat jullie bouwen maar als het geen plugins voor een softwarepakket ofzo zijn zou ik toch kijken of je de externen gewoon toegang kan geven tot alle code... lijkt me alles een stuk makkelijker.

Qua git hosting zou ik kijken naar bitbucket > gratis tot 10 users.

Verder is de feature branch workflow een heerlijke workflow waarbij je heel fijn privé aan een feature kan werken zonder andere mensen lastig te vallen. Code reviews zijn goed te doen en het past ook goed bij agile methodes zoals kanban bijv.

De splitsing die ik aangaf is behoorlijk gescheiden. Ik denk dat de laatste verandering die meerdere gedeeltes omvatte een paar jaar terug was. Maar je hebt gelijk, dit kan voorkomen.

Hoe doe jij de feature branch workflow met code reviews? Open je een pull request of merge je zelf naar master?
En doe je dit in bitbucket of gebruik je een andere host?

Ik zat zelf te denken, iemand die net begint: mag nog niet zelf master bewerken. Een open issue -> maakt branch -> maakt pull request als klaar -> code review, op- en aanmerkingen -> wanneer OK merged ervaren collega de branch.
Als iemand ingewerkt is: kan zelf naar master mergen.

_Erikje_ schreef op zaterdag 16 januari 2016 @ 09:42:
Wat voor andere toolling gebruiken jullie?

Je kunt ook bitbucket of zelf in je eigen cloud gitlab draaien.

VS2013/2015, TortoiseSVN, AnkhSVN, Trello voor issues, svn hosting zelf met VisualSVN Server.
Zelf iets hosten vergt onderhoud, daar willen we eigenlijk juist vanaf. We zijn niet zo'n heel groot team.

[Elijan9]

Github biedt trouwens ook prima SVN ondersteuning: https://github.com/blog/626-announcing-svn-support

[Bigs]

Een pull request workflow werkt super. Of je dit bij Github, Gitlab of Bitbucket doet maakt niet eens zoveel uit, technisch stelt het helemaal niet zoveel voor. Je zult merken dat vooral de menselijke factor de uitdaging vormt; sommige PR's met 500 changes worden in een oogwenk geaccepteerd terwijl er over een PR van 15 regels uren gediscussieerd kan worden. Ik probeer bij ons een beetje de: 'als de applicatie er niet slechter van wordt gewoon mergen en een nieuwe issue aanmaken voor de afwerkpuntjes'. Dat houdt de motivatie erin. Een CI integratie die bij elke PR meteen de tests draait scheelt ook een hoop werk.

Als je SVN repo de structuur '/<module>/{trunk,branches,tags}' volgt kun je dit direct met svn2git opsplitsen naar meerdere repo's. Achteraf in Git opsplitsen gaat je waarschijnlijjk niet lukken zonder verlies van geschiedenis. Als je een andere structuur hebt (bv 'trunk/<module>') moet je misschien overwegen om de branches achterwege te laten als dat mogelijk is.

[ Voor 4% gewijzigd door Bigs op 19-01-2016 11:27 ]

[Bigs]

Elijan9 schreef op dinsdag 19 januari 2016 @ 11:04:
Github biedt trouwens ook prima SVN ondersteuning: https://github.com/blog/626-announcing-svn-support

Github biedt ondersteuning voor SVN clients, niet voor het hosten van SVN repositories. Dat is iets heel anders dus.

[Elijan9]

Bigs schreef op dinsdag 19 januari 2016 @ 11:26:
Github biedt ondersteuning voor SVN clients, niet voor het hosten van SVN repositories. Dat is iets heel anders dus.

...en dat betekend dus dat je gewoon TortoiseSVN en AnkhSVN kunt blijven gebruiken. Ik beweer toch ook niet het tegenovergestelde?

[ Voor 7% gewijzigd door Elijan9 op 19-01-2016 12:01 ]

[CyBeR]

Dat is leuk als je bejaard bent en niks nieuws kunt leren maar verder is de tijd van svn toch echt voorbij.

[Merethil]

CyBeR schreef op dinsdag 19 januari 2016 @ 12:03:
Dat is leuk als je bejaard bent en niks nieuws kunt leren naar verder is de tijd van svn toch echt voorbij.

...Want? SVN is een prima VCS. Het werkt gewoon anders dan Git, maar dat houdt niet in dat het obsolete is.

[Elijan9]

CyBeR schreef op dinsdag 19 januari 2016 @ 12:03:
[...offtopic rant...] de tijd van svn toch echt voorbij.

Offtopic, maar toch interessant om even op in te gaan:
Een Decentralized Version Control systeem is iets wat voor veel bedrijven gevoelig ligt, management wil dan toch zicht en grip op alles wat er gedaan wordt. Zelf vind ik Git ook ideaal werken voor eigen projecten, maar veel organisaties hebben er toch wat moeite mee dat er een complete kopie op alle clients wordt gemaakt en dat er vervolgens volledig offline gewerkt kan worden. Dat is ook een probleem met back-ups maken.

Of zoals iemand op Stackoverflow het mooi beschrijft:

Distributed version control systems (DVCSs) solve different problems than Centralized VCSs. Comparing them is like comparing hammers and screwdrivers.

Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore Good. All developers work (checkout) from that source, and then add (commit) their changes, which then become similarly Blessed. The only real difference between CVS, Subversion, ClearCase, Perforce, VisualSourceSafe and all the other CVCSes is in the workflow, performance, and integration that each product offers.

Distributed VCS systems are designed with the intent that one repository is as good as any other, and that merges from one repository to another are just another form of communication. Any semantic value as to which repository should be trusted is imposed from the outside by process, not by the software itself.

Qua Centralized Version Control systemen is SVN toch wel de meest populaire open-source oplossing. En persoonlijk vind ik dat Github met SVN (client) ondersteuning het beste van beide werelden probeert te leveren...

[CyBeR]

Elijan9 schreef op dinsdag 19 januari 2016 @ 12:59:
[...]

Offtopic, maar toch interessant om even op in te gaan:
Een Decentralized Version Control systeem is iets wat voor veel bedrijven gevoelig ligt, management wil dan toch zicht en grip op alles wat er gedaan wordt. Zelf vind ik Git ook ideaal werken voor eigen projecten, maar veel organisaties hebben er toch wat moeite mee dat er een complete kopie op alle clients wordt gemaakt en dat er vervolgens volledig offline gewerkt kan worden. Dat is ook een probleem met back-ups maken.

Dat zijn allemaal misvattingen. Ja, je kúnt volledig gedistribueerd en offline werken (totdat je iets met elkaar wilt mergen). In de praktijk echter is er vrijwel altijd nog steeds één centrale source of truth, namelijk de online repo in github, gitlab of wat je ook gebruikt om 't zooitje te managen. Dat git zelf een DVCS is betekent niet dat je niet één repo kunt hebben waarvan je zegt, 'dit is de master repo'.

En backups maken is juist makkelijker aangezien iedereen een volledige kopie van de repo heeft. Waarbij natuurlijk ook weer geldt dat als je die centrale repo hebt dat je die zonder problemen kunt backuppen. (En mochten zowel de repo als de backup verloren gaan, dan doet een developer een push en dan heb je alles weer netjes staan.)

Ik wéét dat dit misvattingen zijn omdat ik ze ook had toen ik op m'n werk nog svn gebruikte en enkele ontwikkelaars graag Mercurial wilden.

Qua Centralized Version Control systemen is SVN toch wel de meest populaire open-source oplossing. En persoonlijk vind ik dat Github met SVN (client) ondersteuning het beste van beide werelden probeert te leveren...

SVN is het meest populair omdat CVS dat eerder was en het doel van SVN is letterlijk "een betere CVS zijn". Dat was 't zeker, maar net zoals CVS nu alleen nog door heel klein aantal mensen gebruikt wordt is SVN ook op zijn retour.

[Elijan9]

CyBeR schreef op dinsdag 19 januari 2016 @ 13:20:
[...]
En backups maken is juist makkelijker aangezien iedereen een volledige kopie van de repo heeft.

Dat is dus juist een probleem voor grote bedrijven... Zolang er nog geen goed CVCS is als vervanger voor SVN, blijft deze nog wel eventjes populair, net zoals CVS dat ooit was. (Trouwens, bij CVS waren commits bijvoorbeeld niet eens atomic en zo waren er wel meer grove tekortkomingen. Maar CVS was nooit populair onder bedrijven.)

En met onderlinge afspraken is git weliswaar redelijk centraal te houden e.d., maar dit is niet af te dwingen. Access-control is trouwens slecht geregeld bij git, dat moet al snel met behulp van een update-hook, iets wat Mercurial wel uitstekend geregeld heeft.

[Bigs]

Ik geloof er niets van dat bedrijven aan SVN vasthouden omdat een gecentraliseerd VCS zogenaamd veiliger is. Dat is dan echt een gevalletje misinformatie + stockholm syndrome. Ook met Git is er altijd een centraal repository vanwaar releases worden gedaan, dus dat maakt geen verschil met SVN. Verder is access control prima te regelen met tools als Gitolite.

Subversion "Even snel van branch wisselen, ohnee ik zit in de trein zonder Internet dus ik kan niet bij de server." wie wil dat nou nog. Om over de merges maar niet te spreken.

[Verwijderd]

Bigs schreef op dinsdag 19 januari 2016 @ 15:03:
Subversion "Even snel van branch wisselen, ohnee ik zit in de trein zonder Internet dus ik kan niet bij de server." wie wil dat nou nog. Om over de merges maar niet te spreken.

Wat boeit dat nu? Ik werk alleen op kantoor of thuis aan de software. Ik heb dus altijd toegang tot svn. Merges zijn door de manier waarop wij het werk hebben verdeeld vrijwel altijd pijnloos.

Svn voldoet prima voor al onze projecten, ik zie geen nut in het leren van een nieuw version control systeem, tenzij het gaat om mijn CV opvullen.

[Merethil]

Verwijderd schreef op dinsdag 19 januari 2016 @ 15:45:
[...]

Wat boeit dat nu? Ik werk alleen op kantoor of thuis aan de software. Ik heb dus altijd toegang tot svn. Merges zijn door de manier waarop wij het werk hebben verdeeld vrijwel altijd pijnloos.

Svn voldoet prima voor al onze projecten, ik zie geen nut in het leren van een nieuw version control systeem, tenzij het gaat om mijn CV opvullen.

Hier exact hetzelfde. Voor mijn projecten waar ik daadwerkelijk onderweg aan werk gebruik ik wel Git, maar de specifieke issue met het switchen van branches ben ik daadwerkelijk nooit tegengekomen, gewoon omdat je nu sowieso eigenlijk altijd internet kan hebben, waardoor ik ook met SVN uit de voeten had gekund.

Op mijn werk gebruiken we SVN juist omdat 't makkelijk opzetten, onderhouden (vooral ook permissies en locks) en makkelijk te backupen (gaat lekker mee in onze dagelijkse backup van de server zelf) is. Het is misschien niet de Ultimate World Best Evah VCS, maar het voldoet prima in een team van 10 man.

Mergen is trouwens prima te doen. Ja, als je conflicten hebt niet, maar ik heb tot nu toe geen groter gemak met mergen bij Git gehad dan bij SVN. Als je last hebt van merges bij SVN gebruik je de verkeerde software om de merge te bewerkstelligen. Met Git zit je toch ook niet alleen in de command line te hacken?

[CyBeR]

Elijan9 schreef op dinsdag 19 januari 2016 @ 14:03:
[...]

Dat is dus juist een probleem voor grote bedrijven...

Ik zie niet op welke manier.

En met onderlinge afspraken is git weliswaar redelijk centraal te houden e.d., maar dit is niet af te dwingen. Access-control is trouwens slecht geregeld bij git, dat moet al snel met behulp van een update-hook, iets wat Mercurial wel uitstekend geregeld heeft.

Dan gebruik je Hg, da's ook prima. Alleen CVCS'en kunnen écht niet meer.

[farlane]

CyBeR schreef op dinsdag 19 januari 2016 @ 18:37:
[...]
Alleen CVCS'en kunnen écht niet meer.

Er leven mensen (buiten jouw wereld) die niet dezelfde eisen en wensen hebben als jij. Kortzichtigheid kan *echt* niet meer.

[Gomez12]

CyBeR schreef op dinsdag 19 januari 2016 @ 18:37:
[...]
Dan gebruik je Hg, da's ook prima. Alleen CVCS'en kunnen écht niet meer.

En wat beschrijf jij eerder in dit topic als werkwijze...

Juist : Prop een CVCS werkwijze in een DVCS en ga op die manier doorwerken zodat je niets van de voordelen van DVCS meepakt en alle nadelen van een CVCS behoud, maarja je kan wel leuk op internet zeggen dat CVCS'en echt niet meer kunnen, je moet echt die CVCS voor een DVCS inruilen want ja dat moet nu eenmaal zo en tja, dat je dan een DVCS een beetje in een positie plaatst van een vierkant blokje door een rond gaatje proberen te krijgen dat is niet erg want met een hamer past alles en je hebt in ieder geval de hedendaagse naam in gebruik alleen niet de bijbehorende werkwijze...

Zo ongeveer het belangrijkste kenmerk van een DVCS is juist dat je afstapt van de single source of truth (want dat gaf/geeft veel problemen) en dat je meer toegaat naar multiple sources of truth depending on the wishes.

[alwinuzz]

Even een update
Werken nu met git via GitHub. Werkt super! Het issues/PR systeem is heel handig, goede integratie en handig voor reviews.
De migratie was wel pittig met svn2git en opschonen met filter-branch. Zou dat niet graag nog een keer doen... Maar nu werkt alles op rolletjes. Gebruik als client SmartGit en dat is redelijk noob-friendly.


Dit gevoel heb ik nog wel af en toe

[Ramon]

Kijk dit en je snapt het al een stuk beter

[EngineerCoding]

Op mijn werk gebruiken we assembla, wat een vcs is met geïntegreerd scrum systeem. Hierbij kan men standups maken, tickets (of issues) in een sprint zetten en wat belangrijk is: het heeft een geïntegreerd permissie systeem.
Een groot nadeel: het kost vrij veel, maar dan heb je ook wat. Misschien is dit meer een optie voor in de toekomst, omdat het dan juist overzichtelijker wordt waarbij er, stel 10,programmeurs zijn.
Ik vind het een heel fijn systeem, maar voor kleinere organisaties is github meer dan genoeg. Althans, dat is mijn mening

[Ventieldopje]

EngineerCoding schreef op zaterdag 21 mei 2016 @ 16:56:
Op mijn werk gebruiken we assembla, wat een vcs is met geïntegreerd scrum systeem. Hierbij kan men standups maken, tickets (of issues) in een sprint zetten en wat belangrijk is: het heeft een geïntegreerd permissie systeem.
Een groot nadeel: het kost vrij veel, maar dan heb je ook wat. Misschien is dit meer een optie voor in de toekomst, omdat het dan juist overzichtelijker wordt waarbij er, stel 10,programmeurs zijn.
Ik vind het een heel fijn systeem, maar voor kleinere organisaties is github meer dan genoeg. Althans, dat is mijn mening

Voor kleine organisaties kun je voor een prikke ook JIRA + Bamboo draaien, zolang je niet met meer dan 10 mensen werkt en zelf host. Kost je voor per pakket zo'n $10 per jaar, voor JIRA + Bamboo bijv. dus $20 per jaar aan licenties. Hosten moet je dan wel zelf maar zou je evt. ook intern kunnen doen op een servertje.

[ Voor 10% gewijzigd door Ventieldopje op 21-05-2016 17:19 ]

[BugBoy]

Als je net overschakelt naar Git dan is dat al lastig genoeg. Maak het niet meteen nodeloos complex door submodules te gebruiken. Het gebruik van veel submodules (die soms ook nog genest worden) is erg lastig voor beginnende Git gebruikers.

[InZane]

EngineerCoding schreef op zaterdag 21 mei 2016 @ 16:56:
Op mijn werk gebruiken we assembla, wat een vcs is met geïntegreerd scrum systeem. Hierbij kan men standups maken, tickets (of issues) in een sprint zetten en wat belangrijk is: het heeft een geïntegreerd permissie systeem.
Een groot nadeel: het kost vrij veel, maar dan heb je ook wat. Misschien is dit meer een optie voor in de toekomst, omdat het dan juist overzichtelijker wordt waarbij er, stel 10,programmeurs zijn.
Ik vind het een heel fijn systeem, maar voor kleinere organisaties is github meer dan genoeg. Althans, dat is mijn mening

Nooit van gehoord. Dan zou ik eerder een bekender systeem zoals Jira of TFS gebruiken.

[Ramon]

InZane schreef op vrijdag 27 mei 2016 @ 10:24:
[...]


Nooit van gehoord. Dan zou ik eerder een bekender systeem zoals Jira of TFS gebruiken.

xenofoob? Of heb je nog steekhoudende argumenten?

[ Voor 8% gewijzigd door Ramon op 27-05-2016 11:08 ]

[InZane]

Ramon schreef op vrijdag 27 mei 2016 @ 11:05:
[...]
xenofoob? Of heb je nog steekhoudende argumenten?

Nee helemaal niet. Ik kom nogal eens ergens en ik ben Assembla eigenlijk nog nooit tegengekomen, terwijl ik tools als Jira en TFS (al dan niet in de wolk) wel verschrikkelijk veel zie. Als je dan toch voor een keuze staat, zou ik eerder iets kiezen dat zich in mijn ogen al bewezen heeft.

Daarmee wil ik verder niet gelijk zeggen dat Assembla een slecht keuze is. Ik ken het alleen niet..

[alwinuzz]

Ramon schreef op vrijdag 20 mei 2016 @ 19:53:
Kijk dit en je snapt het al een stuk beter

[video]

Erg interessante video! Leuk ook dat die XKCD erin zit

Alleen al het idee dat een commit naar achteren wijst (parent) helpt mij al verder om te snappen hoe git werkt.
Dus niet commit1 --> commit2 maar commit1 <-- commit2