SVN of linux server?

[SoulRyder]

Binnenkort verhuizen wij met ongeveer 15 man van een ruimte op school naar een kantoor. Op school hebben we weinig mogelijkheden betreft het opzetten van een eigen file server en hebben we gebruik gemaakt van TortoiseSVN.

Omdat er toch vaak wat misgaat met conflicts en xml response errors, ben aan het overwegen of er andere mogelijkheden zijn. We hebben een pc die als server kan dienen en ik heb ervaring met linux. Het leek me zelf een prima idee om op deze pc linux te zetten, en daar dan een file server van te maken. Maar ik heb hier nog geen ervaring mee. Ik ben geen totale leek en als ik een beetje een idee heb wat de mogelijkheden zijn kom ik er wel uit. Maar ik heb zelf geen idee of het uberhaupt wel een optie om te overwegen is.

Kunnen we het beter bij een svn houden? Of is het slim om te kijken naar het opzetten van een linux file server.

Alvast bedankt

Alexander

[CH4OS]

Als je bekend bent met svn, is het dan misschien geen idee om een git repo aan te maken? Is afaik veel minder fout gevoelig. Daarnaast zijn er online ook legio mogelijkheden voor. Github en BitBucket (als je een gesloten repo wilt) zijn volgens mij de bekendste. Je kan, eventueel, ook uiteraard je eigen git server opzetten.

Daarnaast; Linux is een algemene naam voor een legio aan besturingssystemen, svn een protocol om code te delen met elkaar, dat zijn twee hele verschillende dingen dus.

[jeroen3]

Misschien is een nas eenvoudiger in beheer. SVN (of git) werkt overigens ook prima zonder server. Wijs gewoon naar een map voor je remote repo, ook al staat deze op netwerklocatie.

Mocht je denken dan denken dat dropbox of andere automatische file sharing services geschikt zijn om te gebruiken, dan raad ik je dat nu al af. Sowieso raakt dropbox overstuur van svn files (repo of clone), is er ook nog het gebrekkige file locking en niet-tegelijk updaten van de files.

[Ramon]

Wat voor documenten zet je in versiebeheer?

Het probleem van SVN tegenover een ander versiebeheersysteem zoals git is dat een conflict een probleem is bij de eerste en je moet heel goed opletten om die goed te herstellen. Git heeft dit probleem niet en is daarmee veel betrouwbaarder. Voor git kan je gratis bij bitbucket terecht (tot 5 users) of bij github.

Als je nu met SVN vrij vaak conflicten hebt, hoe verwacht je dan dat een simpele fileserver die conflicten gaat oplossen? Behalve in de zin van dat ik jouw of jij mijn documenten altijd overschrijf en er dus geen conflicten zijn, maar wel data die weg is?

[CAPSLOCK2000]

Wat gaat er precies mis? Loop je tegen bugs in TortoiseSVN aan of kunnen je mensen niet met SVN omgaan? SVN is juist een oplossing om problemen met conflicten te voorkomen, of in ieder geval te detecteren en op te lossen. Met z'n allen tegelijk op een centrale fileserver gaan krassen is juist vragen om moeilijk te detecteren conflicten.

[SoulRyder]

Heel erg bedankt voor de reacties

Documenten die erin komen verschillen van unreal script files (waar eigenlijk nooit iets fout gaat) tot photoshop, files jpg, tga, en map en package files van udk, wav, mp3 en zo kan ik nog wel even doorgaan. Meestal gaat het mis bij de artists omdat ze commiten zonder te updaten (Idd niet handig, maar ik kan het blijven uitleggen en het blijft fout gaan, of kijken of er een andere oplossing is nu we meer mogelijkheid hebben om zelf een systeem op te zetten, vandaar deze post)

Ik heb naar Git gekeken maar kreeg het idee dat al je files dan public staan tenzij je per maand betaald, en het liefst ben ik op zoek naar iets wat gratis te gebruiken is. Maar als ik het goed begrijp bij Bitbucket staat het niet public?

Ik merk ook dat we heel weinig gebruik maken van het terug halen van bestanden van anderen, tenzij er iets verkeerd gaat met commiten, maar inderdaad als de files direct overschreven worden kan dit ook voor problemen zorgen als mensen in dezelfde bestanden werken tegelijkertijd.

Ik zal al jullie reacties nog even stuk voor stuk overwegen en als iemand na deze posts nog opmerkingen heeft hoor ik het graag

[xh3adshotx]

https://www.gitlab.com kan je heel makkelijk een eigen GIT server mee opzetten inclusief een GUI. Misschien ook nog het overwegen waard.

[SoulRyder]

Thanks Zal er naar kijken

[CyBeR]

Gitlab kun je ook online gratis (en private) gebruiken.

[CAPSLOCK2000]

SoulRyder schreef op vrijdag 30 mei 2014 @ 10:00:
Meestal gaat het mis bij de artists omdat ze commiten zonder te updaten (Idd niet handig, maar ik kan het blijven uitleggen en het blijft fout gaan, of kijken of er een andere oplossing is nu we meer mogelijkheid hebben om zelf een systeem op te zetten, vandaar deze post)

Het is misschien een beetje onhandig maar het beschermt jullie wel. Het comitten werkt niet omdat er een conflict is. Ik ben vergeet ook regelmatig om te updaten dus heb ik een klein scriptje geschreven dat iedere 10 minuten automatisch een update doet, dat voorkomt de meeste problemen.

Ik heb naar Git gekeken maar kreeg het idee dat al je files dan public staan tenzij je per maand betaald, en het liefst ben ik op zoek naar iets wat gratis te gebruiken is. Maar als ik het goed begrijp bij Bitbucket staat het niet public?

Dat heeft op zich niks met Git te maken maar met de aanbieder. Bitbucket levert ook besloten repo's en Github tegen betaling ook. Als je zelf een GIT server opzet bepaal je het zelf.

[jeroen3]

SoulRyder schreef op vrijdag 30 mei 2014 @ 10:00:
tot photoshop, files jpg, tga, en map en package files van udk, wav, mp3 en zo kan ik nog wel even doorgaan.

Beide genoemde technieken, subversion en git zijn beide gemaakt voor plaintext sourcecode files.

Misschien moet je zoeken naar iets anders?

[Koffie]

Move PNS > PRG

[ZaZ]

Er is sowieso geen oplossing voor conflicts als je de onbekwame gebruikers niet aanpakt.
Verder; As je veel met dat soort binaries werkt zou ik niet naar git of svn kijken maar eerder naar perforce of plastic scm

[Woy]

Sowieso vindt ik je vraagstelling een beetje vreemd. Een linux server is namelijk helemaal geen alternatief voor SVN.

Zeker voor code/scripts wil je gewoon een VCS ( Version Control System ) hebben. SVN is daar een van de voorbeelden voor. De SVN server kun je eventueel op een eigen linux server draaien, maar zoals al genoemd zijn er ook gratis hosting services online.

Dat je problemen met je Artists hebt zul je toch IMHO een beetje op moeten lossen door ze op te leiden. Overigens kan er niet zomaar wat mis gaan als ze committen zonder te updaten, immers zal SVN dan gewoon netjes de melding geven dat er een resource out of date is, en dat er daarom niet gecommit mag worden.

Verder zou ik ook wel oppassen met het zelf opzetten van je VCS ( Of het nou GIT, SVN, TFS, of wat anders is ), want uiteindelijk is je code wel je belangrijkste asset, en het zou zonde zijn als je door het verkeerd te configureren opeens dagen/weken/maanden aan werk kwijt bent. Zeker aangezien jullie zo te zien niet echt de kenis over het opzetten van een VCS hebben. Het hoeft niet perse heel erg ingewikkeld te zijn, maar het is wel iets dat je goed geregeld wil hebben.

Het is denk sowieso verstandig om je eens goed te verdiepen in verschillende strategieen voor versiebeheer. Kijk bijvoorbeeld eens naar de volgende methode ( http://nvie.com/posts/a-successful-git-branching-model/ ).

[ Voor 61% gewijzigd door Woy op 02-06-2014 12:18 ]

[Gomez12]

Wat is nu eigenlijk de wens? Een file-server of een versie-beheer systeem?

Dat is me niet helemaal duidelijk namelijk...

Als de wens een file-server is en je hebt een VCS, tja dan ga je problemen krijgen met je gebruikers omdat die nooit gaan doen wat jij wilt als hun er zelf niet achterstaan.

[bwerg]

Mocht je inderdaad op git/svn uitkomen:
Ik lees iets over school en kantoor, dus ik weet niet of je nu student bent of niet, maar als student kun je bij sommige aanbieders gratis meer gebruikers of een private repo krijgen. Die informatie zou gemakkelijk te vinden moeten zijn op de github/bitbucket-websites.

En ja, als een gebruiker niet aan de workflow gewend is is het soms wat geklooi maar bedenk je wel dat elke keer als er conflicts zijn, dit nog veel slechter zou aflopen zónder versiebeheer. Dan worden files gewoon overschreven. Het loont dus wel om er mee te leren omgaan, dingen copy-pasten werkt in het begin simpel maar aan het einde weet niemand meer hoe het nou allemaal zit.

[ Voor 11% gewijzigd door bwerg op 02-06-2014 12:53 ]

[Woy]

bwerg schreef op maandag 02 juni 2014 @ 12:52:
En ja, als een gebruiker niet aan de workflow gewend is is het soms wat geklooi maar bedenk je wel dat elke keer als er conflicts zijn, dit nog veel slechter zou aflopen zónder versiebeheer. Dan worden files gewoon overschreven. Het loont de moeite dus wel.

Het punt is wel dat de meeste CVS'en niet erg goed samen werken met binary files ( Zoals word documenten e.d., maar ook JPG's en artwork ). Het mergen gaat daar dan natuurlijk niet goed. Maar je hebt natuurlijk wel gelijk dat het dan beter is dat je een conflict krijgt, dan dat het zomaar overschreven wordt, immers heeft er blijkbaar ook al iemand anders wijzigingen gemaakt, en die wil je inderdaad niet zondermeer overschrijven.

[bwerg]

Nee, vandaar ook "mocht je op git/svn uitkomen". Ik heb weinig ervaring met niet-binaries (behalve in .gitignore zetten ), als je binaries direct bewerkt en zo wil delen kun je beter een alternatief gebruiken voor zover daar een praktische variant voor is.

Er worden wel eens binaries in de repo gezet die uit de plaintext files worden gegenereerd (latex -> pdf, code -> executables, etc.) zodat die dan meteen paraat staan maar dat komt altijd neer op "gooi de oude maar weg".

[ Voor 30% gewijzigd door bwerg op 02-06-2014 13:06 ]

[BasieP]

ik lees hier veel mensen die fan zijn van git. Ikzelf werk met svn, en ben hier heel tevreden over.

Waarom zou git beter zijn dan svn?

CptChaos schreef op donderdag 29 mei 2014 @ 16:34:
Als je bekend bent met svn, is het dan misschien geen idee om een git repo aan te maken? Is afaik veel minder fout gevoelig.

Hoezo?

In beide systemen heb je toch kans op conflicten? en ik beide systemen moet je die toch (waar niet te mergen) zelf oplossen?

of is er iets in git wat ik niet weet?

[Woy]

BasieP schreef op maandag 02 juni 2014 @ 19:51:
ik lees hier veel mensen die fan zijn van git. Ikzelf werk met svn, en ben hier heel tevreden over.

Waarom zou git beter zijn dan svn?

Het grote voordeel is local branching. Daardoor is het veel makkelijker om in een branch te ontwikkelen. Verder is het decentralized, waardoor je flexibeler bent met updates/pathches verspreiden ( Je kunt ze bijvoorbeeld eerst alleen naar een collega versturen ).

Hoezo?

In beide systemen heb je toch kans op conflicten? en ik beide systemen moet je die toch (waar niet te mergen) zelf oplossen?

of is er iets in git wat ik niet weet?

Ja in beide gevallen kan je conflicten krijgen, dat is gewoon inherent aan het concept van tegelijk aan een resource werken en die proberen te mergen.

Echter zeker in het verleden was het mergen van branches in SVN veel foutgevoeliger. In GIT is branching en merging gewoon echt een van de basis acties, en is daardoor veel beter uitgewerkt.

Tegenwoordig is SVN daar overigens ook in verbeterd ( vanaf volgens mij 1.5 is er ook een nieuwer branch/merge model ingebouwd ).

[ Voor 7% gewijzigd door Woy op 02-06-2014 20:08 ]

[MSalters]

Branchen? Mergen? In een organisatie waarin commits al een probleem zijn? Dat lijkt een mismatch tussen wat je CVS kan en wat je team kan.

Ik zou svn aanraden, en wel vanwege svn:needs-lock. Je team heeft de hulp van locks nodig. Dat zorgt ervoor dat 1 file maar door 1 persoon tegelijkertijd bewerkt kan worden. Voor binaries is dat de enige correcte keuze, maar Git kan er niet mee omgaan.

[raptorix]

BasieP schreef op maandag 02 juni 2014 @ 19:51:
ik lees hier veel mensen die fan zijn van git. Ikzelf werk met svn, en ben hier heel tevreden over.

Waarom zou git beter zijn dan svn?


[...]

Hoezo?

In beide systemen heb je toch kans op conflicten? en ik beide systemen moet je die toch (waar niet te mergen) zelf oplossen?

of is er iets in git wat ik niet weet?

Geloof me, heb 10 jaar met SVN gewerkt, en nu sinds een klein jaar met GIT, ik zou NOOIT meer terug willen. Overigens is zoals gezegt niet handig om binaries in GIT te zetten.

[BasieP]

raptorix schreef op donderdag 05 juni 2014 @ 11:38:
[...]

Geloof me, heb 10 jaar met SVN gewerkt, en nu sinds een klein jaar met GIT, ik zou NOOIT meer terug willen. Overigens is zoals gezegt niet handig om binaries in GIT te zetten.

geweldige beargumentatie

[Ramon]

Misschien kan je boar eens proberen? https://code.google.com/p/boar/

If you are familiar with vcs software such as Subversion, you might think of boar as "version control for large binary files". But keep reading, because there is more to it.

Boar stores snapshots of directory trees in a local or remote repository and provides tools to ensure that your data is consistent and complete. You can keep just some or all of your data checked out for viewing and editing.

The repository has a simple layout to ensure that the data can easily be extracted even if the original software should be unavailable. This simplicity makes boar ideal for data that needs safe long-term storage.

BasieP schreef op zaterdag 07 juni 2014 @ 10:18:
[...]

geweldige beargumentatie

Git vs SVN:
- Git is distributed. Als je een 'git clone' doet heb je de complete repository met history op je eigen computer staan
- Je 'git commit' tegen je lokale repository, dus je kan committen zonder je collega's ermee lastig te vallen. Je gebruikt 'git push' om je code in de centrale repository te krijgen.
- Als je SVN server down is ben je fucked. Is je git server down, dan voeg je gewoon een nieuwe remote toe en push je je lokale repository daarheen.
- Je kan direct pushen naar de lokale repo's van je collega's.
- In Git is branchen veel sneller, omdat alleen wijzigingen getracked worden.
- Mergen werkt makkelijker en betrouwbaarder dan SVN.
- Je kan de 'staging-area' gebruiken om gewijzigde bestanden of delen van gewijzigde bestanden (line 200 wel, maar 201 niet) klaar te zetten voor een commit, zodat je een logische structuur en goede commit messages aan je individuele commits mee kan geven.

http://blog.teamtreehouse...ch-from-subversion-to-git

[ Voor 45% gewijzigd door Ramon op 07-06-2014 13:58 ]

[JustAnotherDev]

Waar je ook naar zou kunnen kijken is een OwnCloud oplossing, een open-source Dropbox variant. Het biedt in feite dezelfde mogelijkheden als dropbox echter heb je de opslag in eigen beheer. Dan hoeven je artists ook niet meer na te denken over updaten en comitten omdat dit dan automatisch gebeurt.

Zoals hier eerder genoemd is zou ik wel een VCS ( Version Control System ) gebruiken voor source bestanden (scripts, source-code en andere op text gebaseerde bestanden) maar een combinatie van VCS en OwnCloud (of alternatief daarop) lijkt me een goed alternatief.

[Ramon]

Chooman schreef op zaterdag 07 juni 2014 @ 22:55:
Waar je ook naar zou kunnen kijken is een OwnCloud oplossing, een open-source Dropbox variant. Het biedt in feite dezelfde mogelijkheden als dropbox echter heb je de opslag in eigen beheer. Dan hoeven je artists ook niet meer na te denken over updaten en comitten omdat dit dan automatisch gebeurt.

Ik heb even naar OwnCloud gekeken, maar ik zie dat het versioning ondersteund, er staat niets over merging.
Goede merging lijkt me ook belangrijk, aangezien je met versioning wel terug kan naar vorige versies, maar nog steeds bestanden die gewijzigd zijn door anderen kan overschrijven.

[BasieP]

Ramon schreef op zaterdag 07 juni 2014 @ 10:35:
Git vs SVN:
- Git is distributed. Als je een 'git clone' doet heb je de complete repository met history op je eigen computer staan
- Je 'git commit' tegen je lokale repository, dus je kan committen zonder je collega's ermee lastig te vallen. Je gebruikt 'git push' om je code in de centrale repository te krijgen.
- Als je SVN server down is ben je fucked. Is je git server down, dan voeg je gewoon een nieuwe remote toe en push je je lokale repository daarheen.
- Je kan direct pushen naar de lokale repo's van je collega's.
- In Git is branchen veel sneller, omdat alleen wijzigingen getracked worden.
- Mergen werkt makkelijker en betrouwbaarder dan SVN.
- Je kan de 'staging-area' gebruiken om gewijzigde bestanden of delen van gewijzigde bestanden (line 200 wel, maar 201 niet) klaar te zetten voor een commit, zodat je een logische structuur en goede commit messages aan je individuele commits mee kan geven.

http://blog.teamtreehouse...ch-from-subversion-to-git

Een paar van die argumenten zijn outdated, maar opzich klinkt het idd leuk
vooral dat pushen naar lokale repo's van bijv collega's is super. Hoe vaak wil je niet jou code even laten reviewen zonder dat het ingecheckt wordt

[Kanarie]

BasieP schreef op zondag 08 juni 2014 @ 13:37:
[...]


Een paar van die argumenten zijn outdated, maar opzich klinkt het idd leuk
vooral dat pushen naar lokale repo's van bijv collega's is super. Hoe vaak wil je niet jou code even laten reviewen zonder dat het ingecheckt wordt

Daarvoor werken pull requests nog beter.

[raptorix]

BasieP schreef op zaterdag 07 juni 2014 @ 10:18:
[...]

geweldige beargumentatie

Nou joh ga dan lekker door met SVN, enig idee waarom vrijwel elk opensource project kiest voor GIT?
Ik wens je heel veel succes, heerlijk lekker branchen, ik spreek je over een jaar of 4 wel weer.

[LinuX-TUX]

De TS heeft ervaring met Linux, ik lees niet dat 1 van de andere 14 ervaring daarmee heeft. Tevens is GIT niet echt 1 van de makkelijkste DVCS's die ik ken om 'even aan te leren' en "o wat een gebruiksvriendelijkheid".

SVN zou ik wel achter laten en zelf even verdiepen in Git / Mercurial. Deze twee zijn aan elkaar gewaagd en moet je zelf beslissen welke je gaat kiezen ivm leercurve en gebruiksvriendelijkheid. (Ik persoonlijk vind de performance van git onder windows nog steeds crap tov op linux. De vrijheid is groter met git, maar met vrijheden komen ook verantwoordelijkheden en extra leercurves om de hoek kijken.)

[farlane]

Jullie blijven maar dooremmeren over GIT maar welk probleem moet dat eigenlijk oplossen? TortoiseSVN is al bekend, en GIT gaat echt die conflicts niet automagisch oplossen voor de gebruikers. Over branchen en mergen heeft de TS het helemaal niet gehad.

[ZaZ]

farlane schreef op zondag 08 juni 2014 @ 19:36:
Jullie blijven maar dooremmeren over GIT maar welk probleem moet dat eigenlijk oplossen? TortoiseSVN is al bekend, en GIT gaat echt die conflicts niet automagisch oplossen voor de gebruikers. Over branchen en mergen heeft de TS het helemaal niet gehad.

Precies. Ik word trouwens echt af en toe niet goed van de git-fanboys. Begrijp me niet verkeerd, ik gebruik het zelf ook en heb jarenlang svn gebruikt, maar ik heb tot nu toe geen wonderen gezien ofzo, terwijl ik al meer dan anderhalf jaar 'over' ben en er elke dag de hele dag mee werk.
De conflicten waar git zoveel beter mee zou moeten zijn heb ik eigenlijk nooit echt gemerkt. Ik vroeg het mij al af voordat ik het ging gebruiken omdat ik in svn eigenlijk alleen conflicten had waar ik ze verwachtte. Op de plekken waar wijzigingen plaats hebben gevonden en het scm niet zelf kan kiezen dus mij het op laat lossen.
Die conflicten heb ik in git (natuurlijk) nog steeds.
Het argument dat branchen in git goedkoop is. Dat is het in svn ook? Daar is het ook niet zo dat er een kopie gemaakt wordt ofzo hoor. Dat is gewoon een pointertje naar de revisie. Het mergen heb ik eigenlijk in svn ook nooit echt gezeik mee. Vroeger had je dat je je bewust moest zijn welke kant je op ging mergen (bijv van of naar een feature branch) en moest je dan wel een --reintegrate optie toevoegen omdat je anders later in gezeik kwam, maar dat is ook al een tijdje niet meer zo en gaat dat automatisch.

Maar goed, er zijn heus wel voors en tegens, maar het is dus niet zo omdat git nu heel cool is dat dat het beste scm is voor elke klus.

Verder advies heb ik al gegeven. Je hebt een cultuurprobleem en als je die oplost en met versiebeheer gaat werken dan ga je niet met dropboxen of owncloud lopen klooien maar met versiebeheer.
Dan kies je dus ook een versiebeheersysteem die aan je eisen voldoet. Een perforce of plasticscm lijkt mij het beste daarin. Het is ook niet voor niets dat in de game-industrie dat veel gebruikt wordt. Je hebt goede plugins om je audiofiles en grafische files te 'diffen' enzo
Er zijn er vast wel meer, maar daar heb ik geen ervaring mee.

[Verwijderd]

CptChaos schreef op donderdag 29 mei 2014 @ 16:34:
Als je bekend bent met svn, is het dan misschien geen idee om een git repo aan te maken? Is afaik veel minder fout gevoelig. Daarnaast zijn er online ook legio mogelijkheden voor. Github en BitBucket (als je een gesloten repo wilt) zijn volgens mij de bekendste. Je kan, eventueel, ook uiteraard je eigen git server opzetten.

Daarnaast; Linux is een algemene naam voor een legio aan besturingssystemen, svn een protocol om code te delen met elkaar, dat zijn twee hele verschillende dingen dus.

Linux is geen OS, ook geen groep OS'en. Het is een kernel waar men hun OS op kan baseren (GNU, Android).

binnen GNU/Linux heb je weer distro's als Linux Mint, Debian en Ubuntu. De topicstarter bedoelt met Linux "een distro gebaseerd op GNU/Linux".

Ontopic: Git! (of Mercurial)

[Verwijderd]

Verwijderd schreef op maandag 09 juni 2014 @ 12:58:
[...]


Linux is geen OS, ook geen groep OS'en. Het is een kernel waar men hun OS op kan baseren (GNU, Android).

binnen GNU/Linux heb je weer distro's als Linux Mint, Debian en Ubuntu. De topicstarter bedoelt met Linux "een distro gebaseerd op GNU/Linux".

Ontopic: Git! (of Mercurial)

Ik steun System76 met zijn mening. Ik kan men Git aanraden.

[kwaakvaak_v2]

Git, SVN.. iets wat versies beheerd is prima. Ze hebben allemaal voor en nadelen.

Wat ik prettig aan GIT vind is dat je niet zoveel afval hebt in je structuur, er is maar 1 .git directory in je project ipv in elke directory een .svn directory. Je kunt dingen gewoon verplaatsen met je IDE of andere file manager zonder dat je in de problemen komt.

En voor de rest, wat je ook weg zet, zorg voor backups.. Want hoe leuk versie beheer lokaal ook is, het is geen backup. Als je server afbrand om wat voor reden dan ook moet je nog steeds terug kunnen zetten. (en hier kan GIT een voordeel zijn, door je repo's via een script elke nacht naar bijvoorbeeld Bitbucket te pushen)
Ik heb zoiets een tijd thuis gedraaid, Gitlab op een locale server, en dan elke nacht naar bitbucket pushen. Tot dat ik tot de conclusie kwam dat ik net zo goed in een keer naar bitbucket kon pushen omdat ik toch voornamelijk in mijn eentje werkte

[Refro]

Ramon schreef op zaterdag 07 juni 2014 @ 10:35:
Misschien kan je boar eens proberen? https://code.google.com/p/boar/


[...]


[...]

- Als je SVN server down is ben je fucked. Is je git server down, dan voeg je gewoon een nieuwe remote toe en push je je lokale repository daarheen.

Oh ja en je continious integration, je 8 collegas over 3 tijdzones en static analysis pakketten weten hier ook direct van en gaan automagisch over naar de nieuwe locatie.

- In Git is branchen veel sneller, omdat alleen wijzigingen getracked worden.

Dit doet SVN ook, alleen de wijzigingen vanaf het branch punt worden opgeslagen.

Wat ik prettig aan GIT vind is dat je niet zoveel afval hebt in je structuur, er is maar 1 .git directory in je project ipv in elke directory een .svn directory.

Dit is tegenwoordig bij SVN ook zo.

Moet me bij een aantal andere aansluiten wat je gebruikt maakt niet zo veel uit als het maar een beetje modern is. SVN past daar ook nog steeds bij. Gebruikt zelf van af 2000 VSS, vanaf 2003 SVN en vanaf 2012 GIT. Nog steeds alles door elkaar maar gelukkig het meeste SVN en GIT.

[Ramon]

Refro schreef op vrijdag 13 juni 2014 @ 08:05:
[...]


Oh ja en je continious integration, je 8 collegas over 3 tijdzones en static analysis pakketten weten hier ook direct van en gaan automagisch over naar de nieuwe locatie.

Wat is dat nou voor een argument? Het punt was dat bij git iedereen letterlijk automatisch een kloon heeft van de repo. Bij SVN is dat niet zo. Dus in het geval van nood kan je je git repo zonder problemen migreren (git remote add, git push), iets wat bij SVN lastiger is.

Natuurlijk moet je dat dan wel communiceren met je collega's, maar dat lijkt me een given.

Maar de hele git vs SVN discussie is een beetje redundant omdat ze beide niet echt geschikt zijn voor binary files. @TS: Heb je boar al geprobeerd uit mijn vorige post? https://code.google.com/p/boar/

[kwaakvaak_v2]

Refro schreef op vrijdag 13 juni 2014 @ 08:05:


Dit is tegenwoordig bij SVN ook zo.

Check.. dat wist ik niet, ben ook al tijdje over op GIT, vooral omdat het in web-land toch beetje de defacto standaard is geworden.