[ALG] Welke Source Repository voor hobby project?

[Verwijderd]

Sinds een aantal maanden klus ik aan een eigen CMS'je, voornamelijk om ervaring op te doen met php / sql / javascript. Soms werk ik er dagen achtereen aan, dan weer ligt het 3 weken stil. Van tijd to tijd maak ik backups, maar dat gaat vrij spartaans: ik kopieer gewoon de hele servermap naar een zipbestand, dat ik onder de huidige datum opsla.

Steeds vaker bedenk ik mij "had ik dit of dit niet in een eerdere versie zitten?". Dan kan ik 20 zipbestanden doorspitten, op zoek naar het juiste bestand. Dat is dus niks. Oplossing: een source repository (zojuist geleerd via Google)

Het blijkt dat Subversion het meest bekende systeem is, maar ik schrik een beetje van hoe uitgebreid het is. Kent iemand een eenvoudig alternatief systeem dat geschikt is voor een hobby project als het mijne met maar 1 gebruiker (waardoor er dus geen uitgebreide rechten hoeven te worden toegekend, bijvoorbeeld)?

[Gomez12]

Tja, je kan het zo ingewikkeld inrichten als je wilt zal ik maar zeggen...

Persoonlijk werk ik graag met GiT vanwege de functionaliteit, maar ik mis er onder windows nog goede shell-tools voor, waardoor ik over het algemeen gewoon terugval op een subversion in combinatie met tortoisesvn.

Subversion heeft wmb de onhandige eigenschap dat het overal files wil neerplanten waar ik helemaal niet op zit te wachten, maar qua gebruik via tortoisesvn vind ik het perfect werken. Gewoon enkel maar commiten en als het uitgebreider wordt kan je altijd nog een trax oid aan de serverkant neerzetten.

Git mis ik vooral de webinterface voor grotere projecten ( ik heb de neiging om gewoon binary's / dbase dumps er ook maar in te gooien, veranderen bijna nooit en met eigen colo server heb ik toch ruimte zat ) wat op de publieke websites al snel prijzig wordt als je het niet 100% publiekelijk wilt hebben.

Enige waar ik wel vanuit ga is dat je een eigen server oid hebt met voldoende ruimte, local repository's vind ik niet helemaal werken. Een source repository ga je nooit meer iets uitkrijgen ( zonder giga-veel moeite ) dus het wordt alleen maar groter...

[djluc]

Je hebt eigenlijk 2 grote, SVN en GIT. Elk heeft zo zijn eigen voordelen, beetje afhankelijk van of je op Windows of Linux/Mac werkt kan je de keuze bepalen. Over het algemeen werkt SVN op Windows het lekkerste en GIT op de overige platforms. Op beide werkt het echter en vaak is het dan ook een verschil van voorkeur. Bij GIT heb ik nooit echt rechten in hoeven te stellen op lokale machines dus dat lijkt me niet zo'n issue.

Je kan bijvoorbeeld hier eens kijken om een online storage te gebruiken:
http://www.straw-dogs.co....project-hosting-services/

Je hebt dan meteen een back-up van je gegevens op een externe locatie.

[Verwijderd]

Gomez12 schreef op dinsdag 02 februari 2010 @ 21:46:
Enige waar ik wel vanuit ga is dat je een eigen server oid hebt met voldoende ruimte, local repository's vind ik niet helemaal werken. Een source repository ga je nooit meer iets uitkrijgen ( zonder giga-veel moeite ) dus het wordt alleen maar groter...

Nou, ... ik heb dus 1 PC waarop ik lokaal Apache en MySQL draai (data, zoals htdocs en mysql bin staan op externe schijf). De bedoeling is eigenlijk om op diezelfde PC een SVN / Subversion / Git server en client te installeren. Maar ik begrijp uit je reaktie dat dat geen goed idee is? Wat bedoel je met "daar ga je nooit meer iets uitkrijgen"? Kan ik geen backup maken van zo'n source repository en die eenvoudig naar een andere PC / Server kopieren als ik op mijn PC te weinig ruimte zou krijgen?

[Voutloos]

Dat kan inderdaad. Maar in je eentje mag je redelijk je best doen om de voor de repo benodigde ruimte een probleem te laten zijn.

Gewoon doen is het devies. Kies er een en goan.

[Nick_S]

Je zou eens kunnen kijken naar github of Sourceforge. Dan heb je gelijk een sourcerepository, website, bugtracking in 1.

[MBV]

Pak lekker SVN. Zolang je niks moeilijks wil doen is het zo simpel als simpel wezen kan:
- maak een repository aan (liefst een echte SVN server, 100 howto's voor te vinden, en als je al apache heb geinstalleerd moet dat geen punt zijn)
- maak in die repository een map met je projectnaam, met subdirectories 'trunk', 'tag' en 'branches'. Die heb je nu niet nodig, maar als je er meer mee gaat doen wordt dat ooit handig (en het staat niet in de weg)
- maak een checkout van de trunk-map op je PC m.b.v. tortoise (als je windows gebruikt) of je IDE
- commit na elke wijziging, aan het einde van de dag, of wanneer je maar wilt

Dan heb je een backup van de huidige versie, en als je rechtsklikt op de map kan je met tortoise 'show log' doen om een oude versie tevoorschijn te toveren. Simpeler kan versiebeheer niet.

[Gomez12]

Verwijderd schreef op dinsdag 02 februari 2010 @ 22:01:
[...]

Nou, ... ik heb dus 1 PC waarop ik lokaal Apache en MySQL draai (data, zoals htdocs en mysql bin staan op externe schijf). De bedoeling is eigenlijk om op diezelfde PC een SVN / Subversion / Git server en client te installeren. Maar ik begrijp uit je reaktie dat dat geen goed idee is? Wat bedoel je met "daar ga je nooit meer iets uitkrijgen"? Kan ik geen backup maken van zo'n source repository en die eenvoudig naar een andere PC / Server kopieren als ik op mijn PC te weinig ruimte zou krijgen?

Externe schijf betekent dat je enkel kan committen als die schijf eraan hangt ( even vanuit SVN gezien dan, GiT zou je nog wel kunnen committen ), dat vind ik niet echt ideaal.

Plus dat ik lokaal nogal redelijk vaak de behoefte heb om data te verplaatsen ( werkt niet lekker met ingestelde paden etc ) en dat ik lokaal nog wel eens schijfruimte te kort kom ( waarna je dus weer een verplaatsing / tijdelijke inzip-actie krijgt etc ). Dat gekoppeld aan het feit dat ik toegang tot een server heb, die is standaard al mijn externe backup, die heeft ook nog eens extra backup mogelijkheden geregeld.

Plus het feit dat ik niet altijd enkel op mijn eigen computer aan een project werk ( een source repository is wel op een usb-disk te zetten en over te zetten naar een andere pc, maar het is toch even iets meer instelwerk als een zip uitpakken ) en ik eigenlijk altijd overal inet heb, dat maakt het voor mij persoonlijk onhandig om een lokale repository te hebben.

Een repository is wel van pc / pad te veranderen, maar het is toch altijd iets meer werk dan een simpele zip uitpakken ( je moet ook tortoisesvn instellingen veranderen etc ).

Voor mij werkt een repository juist als het simpel werkt, je kan het ook helemaal handmatig draaien en met cli-tools fysiek committen naar een bepaalde directory, maar voor mij werkt het pas echt als ik enkel in eclipse / netbeans / rechtermuisknop / scite maar hoef te kiezen voor commit en dan mijn commentaar kan invullen, zou ik daarin ook elke keer het pad in moeten vullen ( inclusief zo af en toe tikfouten etc ) dan zou ik veel minder commits doen.
En die simpele eclipse/netbeans/rechtmuisknop commits die vereisen instellingen waar de repository staat en daar heb ik geen zin om elke keer alle paden aan te moeten passen...

Voutloos schreef op dinsdag 02 februari 2010 @ 22:05:
Dat kan inderdaad. Maar in je eentje mag je redelijk je best doen om de voor de repo benodigde ruimte een probleem te laten zijn.

Zeg dit niet te snel, ik heb projecten gezien waarbij ze bijvoorbeeld mp3 via een flash-player afspeelden, elke dag een aantal andere mp3's. Dat gaat zonder exclusions toch best hard oplopen na een paar maanden.
Of mensen die psd's van 100'en MB's gingen bijhouden in hun repository voor een siteje van 10 Mb.

Dan ga je je op een gegeven moment wel afvragen waarom je repository voor dat project 1.5 Gb is terwijl als je de laatste data eruit haalt je maar 10Mb terugkrijgt

Zoals ik al eerder zei, het is heel erg moeilijk ( zeg maar normaal gesproken onmogelijk ) om een bestand uit je repository te verwijderen. 1x een groot binair bestand gecommit betekent dat deze altijd in je repository blijft zitten totdat je de hele repository opnieuw opbouwt. Al is het bestand 4 jaar geleden van schijf verdwenen, in je repository neemt hij nog steeds ruimte in.
Bij source oid is dat gewenst en juist de bedoeling van een repository, maar binary's kunnen wel eens minder gewenst zijn...

[ Voor 20% gewijzigd door Gomez12 op 02-02-2010 22:25 ]

[Voutloos]

Paden: zorg voor een consistente workflow en het boeit verder nooit meer.
Opslagruimte: Wakker liggen van 1.5 GB is echt enorm 1998.
Binaire files: Bij alle adds moet je gewoon nadenken of het in de repo moet, lost vaak ook bovenstaande punt op.

Je denkt in problemen. TS kan prima beginnen met het advies van MBV (en wellicht niet per se die ene partitie van 50 MB kiezen ), of met genoemge externe hosting.

[ Voor 20% gewijzigd door Voutloos op 02-02-2010 22:36 ]

[Gomez12]

Voutloos schreef op dinsdag 02 februari 2010 @ 22:35:
Paden: zorg voor een consistente workflow en het boeit verder nooit meer.
Opslagruimte: Wakker liggen van 1.5 GB is echt enorm 1998.

Voor desktops wel, maar laptops hebben afaik nog wel beperkte ruimte en externe disks wil ik ook niet overal heenslepen.
En ach, als ik op mijn repository kijk en daar 80Gb zie staan verspreid over ongeveer 50 projecten dan denk ik nu met externe server idd opslagruimte boeit me niets en bins kan ik er redelijk bijgooien.
Maar 80Gb had ik niet zomaar even op mijn laptop altijd vrijgehad ( en ja, die 80Gb is niet van gisteren op vandaag zit ietwat jaren werk in ) .

Dan denk ik toch echt, goede voorbereiding haalt een hoop werk in de toekomst weg.

Binaire files: Bij alle adds moet je gewoon nadenken of het in de repo moet, lost vaak ook bovenstaande punt op.

Ach, bij de meeste projecten wil ik helemaal niet nadenken. Gewoon dumpen is mijn devies, anders heb ik altijd net dat ene bestandje nodig wat niet in de repo staat
Niet erg, maar begrijp wel dat je repo's daar groter door worden...

[BCC]

Gomez12 schreef op dinsdag 02 februari 2010 @ 22:50:
Ach, bij de meeste projecten wil ik helemaal niet nadenken. Gewoon dumpen is mijn devies, anders heb ik altijd net dat ene bestandje nodig wat niet in de repo staat
Niet erg, maar begrijp wel dat je repo's daar groter door worden...

Git doet hierom binary diffs, wat een heel stuk efficiënter is dan SVN .

Git is voor een beginner een stuk eenvoudiger dan SVN omdat het opzetten zo simpel is:

code:

cd project
git init
git commit -a -m "Initial commit"

Dat gaat je niet lukken met SVN Dan zit je gelijk aan een server vast. En dan het liefst met webdav internet access via https met een bijbehorende een trac .

Windows support schijnt een stuk verbeterd te zijn trouwens, maar ik gebruik het onder OSX en Linux.

[ Voor 35% gewijzigd door BCC op 02-02-2010 22:56 ]

[MBV]

@Gomez: geen probleem hoor, je moet even een command-line trucje uithalen: http://subversion.apache.org/faq.html#removal
Ik heb ook ooit iemand op z'n kop gegeven voor bij mijn server een gigabyte in SVN zetten. Verder valt het best mee: ondanks dat er een PDF-bestand van inmiddels meer dan 30 MB (146 versies) in bij wordt gehouden, en 2 presentaties van 20 MB (24 versies) is mijn repository maar 700MB. Checkout van de hele tree is 936MB (150MB aan tags).
Verder snap ik absoluut niet wat jij er allemaal voor problemen bij haalt. Ik weet dat dit tweakers.net is, maar for crying out loud, koop gewoon een nieuwe harde schijf

@BCC: dat doet SVN ook bij mijn beste weten. PDF wordt als binary gezien, terwijl het toch redelijk consistent is als je het met Latex genereert. De diff is dus erg klein: de plaatjes die er als blob instaan zullen niet veranderen.
Ik moet toegeven dat ik nog nooit heb gewerkt met GIT, maar het hele gedistribueerde concept vind ik een stuk lastiger te begrijpen. SVN is gewoon een tree die op de server staat, waar elk bestand meerdere versies kan hebben. Dat is maar 1 dimensie extra t.o.v. explorer. Daarnaast is de GUI-support in de vorm van Tortoise erg goed, is er ook zoiets voor GIT?

Je zit trouwens niet aan een server vast: een willekeurige lokatie aanwijzen, rechtsklikken, en met tortoise zet je er een repository neer. Ik vind het niet netjes, maar het werkt prima

[ Voor 43% gewijzigd door MBV op 02-02-2010 23:07 ]

[Nick_S]

BCC schreef op dinsdag 02 februari 2010 @ 22:52:
[...]


Git doet hierom binary diffs, wat een heel stuk efficiënter is dan SVN .

Git is voor een beginner een stuk eenvoudiger dan SVN omdat het opzetten zo simpel is:

code:

cd project
git init
git commit -a -m "Initial commit"

Dat gaat je niet lukken met SVN Dan zit je gelijk aan een server vast. En dan het liefst met webdav internet access via https met een bijbehorende een trac .

Windows support schijnt een stuk verbeterd te zijn trouwens, maar ik gebruik het onder OSX en Linux.

Dat valt met SVN ook wel weer mee, hoor.

code:

svnadmin create /repos/newproject
svn co file://repos/newproject newproject
cd newproject
cat bla > file.txt
svn add file.txt
svn ci -m 'Eerste commit'

edit:

En over bestanden uit je repository weg gooien zou ik me ook maar niet te veel zorgen maken. Dit is functionaliteit die vanaf SVN 1.7 er standaard inzet. Deze moet van het voorjaar uitkomen.

[ Voor 10% gewijzigd door Nick_S op 02-02-2010 23:17 ]

[Gomez12]

MBV schreef op dinsdag 02 februari 2010 @ 22:57:
@Gomez: geen probleem hoor, je moet even een command-line trucje uithalen: http://subversion.apache.org/faq.html#removal

Zoals je zelf zegt, ik weet dat het t.net is, maar for crying out loud, je begrijpt toch hopelijk wel dat niet iedereen zin heeft in dit soort trucjes?

Verder snap ik absoluut niet wat jij er allemaal voor problemen bij haalt. Ik weet dat dit tweakers.net is, maar for crying out loud, koop gewoon een nieuwe harde schijf

Lol, iemand op zijn kop geven omdat hij 1Gb commit en dan aankomen met command line geintjes om dat er weer uit te halen. En dan tegen mij zeggen dat ik een nieuwe hdd moet kopen
Ik zou bijna iets zeggen over ga eerst eens met een grotere repo werken...

Ik probeer enkel wat advies te geven voordat iemand nu onbezonnen begint en over een half jaar denkt had ik het toch maar anders aangepakt.

[boe2]

MBV schreef op dinsdag 02 februari 2010 @ 22:11:
Pak lekker SVN. Zolang je niks moeilijks wil doen is het zo simpel als simpel wezen kan:

Als je er niet van wakker ligt dat je code online staat kan je gewoon je eigen SVN ruimte krijgen op http://code.google.com/hosting/createProject .
Je krijgt 1 GB opslagruimte (ruim voldoende voor je CMS projectje) en je hoeft je geen zorgen te maken om backups. Ikzelf heb meerdere persoonlijke projectjes in een enkele google repository gehost staan .

[Niemand_Anders]

Als je alles onder Windows installeerd dan kun je op de website van VisualSVN een volledig voor subversion geconfigureerde apache installatie downloaden. Je kan dan zowel windows als 'private' users gebruiken.

Inmiddels werken wij al ruim 2 jaar met Team Foundation Server (source repository van Microsoft) welke middels een svnbridge ook via een svn client toegankelijk is. Het zal niet als een verrassing komen dat TFS zeer goed in een Windows omgeving integreerd.

Maar het beste advies welke ik je kan geven is, maak gewoon bij github, codeplex, google code en sourceforge een aantal open source accounts aan en probeer ze gewoon. Ruim 80% van de opensource projecten bestaat uit slechts 1 persoon. Maak gewoon via elk account een hello world project en vergelijk ze en degene welke je het fijnst vind werkt kun je vervolgens lokaal installeren, configureren en gebruiken. De aangemaakte open source accountjes kun je eventueel weer sluiten.

[Serpie]

Ik gebruik SourceGear, het is een beetje verborgen op de site maar de tools zijn gratis voor single user gebruikers:
http://support.sourcegear.com/viewtopic.php?t=252

Zowel installatie als gebruik zijn zeer eenvoudig.

[Soultaker]

Subversion is een gecentraliseerd VCS, vooral bedoeld als betere versie van CVS, maar verder qua insteek enigzins ouderwets. Als je een gecentralizeerd VCS wil gebruiken, lijkt Subversion me wel dé keuze. Stabiel, goede tool support (ook onder Windows), werkt uitstekend. Wel is een webserver een vereiste (maar die kan natuurlijk ook lokaal draaien).

Git, Mercurial, Bazaar, darcs en dergelijke zijn gedistribueerde systemen, dus zonder centrale server, maar als je enige redundantie wil, zul je je repository toch naar een andere computer willen kopiëren. De manier van werken is wat anders dan met traditionele systemen zoals CVS, maar aangezien je daar geen ervaring mee hebt, is dat waarschijnlijk geen groot bezwaar. De gedistribueerde tools zijn nog wel experimenteler, en de performance en Windows support wisselt. Git is snel (en wat mij betreft dé DCVS tool) maar onder Windows niet echt handig. Mercurial of eventueel Bazaar is dan wellicht een betere keuze.

Nick_S schreef op dinsdag 02 februari 2010 @ 22:10:
Je zou eens kunnen kijken naar github of Sourceforge. Dan heb je gelijk een sourcerepository, website, bugtracking in 1.

Kanttekening daarbij is dat je al je broncode dan wel publiek maakt. Lijkt me voor hobbyprojectjes niet echt de bedoeling. Klein beginnen lijkt me een betere aanpak.

Ik ben geneigd om je Subversion aan te raden om mee te beginnen, om de volgende redenen:
• elke vorm van version control is beter dan niets;
• Subversion is relatief eenvoudig om te gebruiken, en maakt het je moeilijk jezelf in de nesten te werken;
• het is dermate stabiel en populair dat als je later op een ander systeem over wil schakelen, je waarschijnlijk je repository makkelijk kunt converteren.

[ZaZ]

Soultaker schreef op woensdag 03 februari 2010 @ 08:55:
Wel is een webserver een vereiste

Dat lees ik vaker, maar dat is niet waar.
Ik draai op meerdere plekken een Subversion server zonder Apache of wat dan ook erop.
Je kunt gewoon met een SVN client via het svn:// protocol je reps benaderen

[Soultaker]

Oh ja, dat is waar ook. Goed punt.

Dan heb je natuurlijk nog net zo goed een server draaien (wat bijvoorbeeld voor Git niet nodig is).

[Nick_S]

Soultaker schreef op woensdag 03 februari 2010 @ 09:37:
Oh ja, dat is waar ook. Goed punt.

Dan heb je natuurlijk nog net zo goed een server draaien (wat bijvoorbeeld voor Git niet nodig is).

Of, zoals ik hierboven al liet zien, kun je ook via het file:// protocol draaien. Dan heb je helemaal geen server nodig.

[Sardaukar]

Het lijkt erop dat het weer gaat uitdraaien op een discussie tussen gedistribueerd en gecentraliseerd. Al vaak genoeg hier aan bod geweest:

http://gathering.tweakers.net/forum/list_messages/1335730

Overigens zou ik voor Git gaan omdat je met een gedistribueerd systeem ook gecentraliseerd kan werken.

[Hydra]

Zelf gebruik ik met veel plexier SVN i.c.m. codeplex. Ik zit er alleen wel over te denken op m'n servertje een SVN repo in te richten omdat ik dan niet van een 3rd party afhankelijk ben, maar codeplex heeft ook weer de mogelijkheden je project te hosten enzo.

[.oisyn]

Nou laat ik dan perforce nog maar weer eens pluggen. Rock stable, kan goed overweg met extreem grote repositories (>1TB), en beschikt over veel fatsoenlijke visuele tools.

[Sardaukar]

.oisyn schreef op woensdag 03 februari 2010 @ 11:07:
Nou laat ik dan perforce nog maar weer eens pluggen. Rock stable, kan goed overweg met extreem grote repositories (>1TB), en beschikt over veel fatsoenlijke visuele tools.

Volgens mij wordt er expliciet gevraagd om een VCS voor een hobbyproject. Is Perforce dan niet een klein beetje overkill?

[ZaZ]

En gaat heel goed samen met binaries, alleen is ie niet gratis dacht ik

[beany]

ZaZ schreef op woensdag 03 februari 2010 @ 11:21:
En gaat heel goed samen met binaries, alleen is ie niet gratis dacht ik

2 user licentie is gratis
SourceGear heeft iets soortgelijks. Weet alleen niet meer of dat 1 of 2 licenties gratis zijn.

[ Voor 18% gewijzigd door beany op 03-02-2010 11:23 ]

[.oisyn]

Sardaukar schreef op woensdag 03 februari 2010 @ 11:20:
[...]


Volgens mij wordt er expliciet gevraagd om een VCS voor een hobbyproject. Is Perforce dan niet een klein beetje overkill?

Waarom is het overkill? Ik gebruik het zelf ook voor m'n hobby projectjes, ik vind er niets overkill aan. Het biedt gewoon de features die je van een VCS kan verwachten, en daarnaast is het ook nog eens heel goed in het managen van binaries, mocht je die in willen checken.

[DiedX]

Perforce zal ik zo eens naar kijken. Zelf zeer goede ervaringen met SVN en HG (Mercurial). HG heeft voor de TS dat je een volledige checkout van de repo hebt. Dat kan oplopen qua ruimte.

Voor een hobbyproject - uitgaande van windows - zou ik (weer) voor SVN gaan...

[Sardaukar]

DiedX schreef op woensdag 03 februari 2010 @ 11:32:
Perforce zal ik zo eens naar kijken. Zelf zeer goede ervaringen met SVN en HG (Mercurial). HG heeft voor de TS dat je een volledige checkout van de repo hebt. Dat kan oplopen qua ruimte.

Voor een hobbyproject - uitgaande van windows - zou ik (weer) voor SVN gaan...

Oh, het is een prima VCS, daar geef ik je gelijk in.

Het wordt alleen lastig als je ooit de repository met meerdere mensen wilt gebruiken. Dan moet je gaan betalen (niet leuk met die prijzen) of gaan converteren naar een ander VCS.

(Offtopic: zeker voor dit soort essentiele tooling heeft open-source bij mij altijd de voorkeur)

[MBV]

.oisyn schreef op woensdag 03 februari 2010 @ 11:30:
[...]

Waarom is het overkill? Ik gebruik het zelf ook voor m'n hobby projectjes, ik vind er niets overkill aan. Het biedt gewoon de features die je van een VCS kan verwachten, en daarnaast is het ook nog eens heel goed in het managen van binaries, mocht je die in willen checken.

In welk opzicht is het beter dan SVN? Ik heb er ook best veel binaries (PDF-bestanden, openoffice/MS office bestanden, PNG's, JPEG's, etc) in zitten, en toch is de repository-size maar 50 MB groter dan de bestanden uitgecheckt (tags in checkout reken ik dan niet mee, die hoeft SVN natuurlijk niet apart op te slaan). En dat ondanks veel versies van iig de PDF's.

[.oisyn]

Geen idee, ik ken SVN niet goed.

[Sardaukar]

MBV schreef op woensdag 03 februari 2010 @ 11:54:
[...]
, en toch is de repository-size maar 50 MB groter dan de bestanden uitgecheckt (tags in checkout reken ik dan niet mee, die hoeft SVN natuurlijk niet apart op te slaan). En dat ondanks veel versies van iig de PDF's.

Ik heb hier een repository waarvan de working copy 850 MB is. Deze is als repository 350 MB met redelijk wat edits...(mental note: ophouden met reclame maken voor Git)

[MLM]

Wat ik heel erg irritant aan SVN vind is dat als je een sourcetree met een grote hoeveelheid kleine bestanden wilt in- of outchecken, dat het zo ONTZETTEND langzaam gaat. Ik denk dat het voor elke file een aparte request doet ofzo, en dat de overhead veel te groot is daardoor. Maar goed, ik kan niet zeggen of dat ook het geval is met andere source control systemen

Voor de rest heb ik altijd al SVN gebruikt zowel voor studie als andere zaken, en het werkt best lekker! En zoals al eerder genoemd, google draait een SVN waar je gewoon een repo kan aanmaken, mits je een open-source licentie gebruikt.

[Nick_S]

Sardaukar schreef op woensdag 03 februari 2010 @ 12:45:
[...]


Ik heb hier een repository waarvan de working copy 850 MB is. Deze is als repository 350 MB met redelijk wat edits...(mental note: ophouden met reclame maken voor Git)

Je moet alleen niet de repository met je working copy vergelijken, maar je repository met een export. In je workingcopy staan namelijk alle bestanden al twee keer + nog meer metainformatie.

Edit: Ik dacht dat het over SVN ging. Deze post heeft dus betrekking op SVN en niet op GIT.

[ Voor 13% gewijzigd door Nick_S op 03-02-2010 14:06 . Reden: Verduidelijking van wat je met elkaar moet vergelijken. ]

[MBV]

@MLM: eens
@Nick_S: oh shit, even vergeten. Dan is de repo dus 2x zo groot als de actuele inhoud.

[Nick_S]

Nee, je working copy is ongeveer 2 x zo groot als die revisie (meestal HEAD) in de repository. Dus in jouw geval is HEAD ongeveer 425 MB groot, terwijl je repo (dus alle revisies samen) maar 350 MB zijn.

Edit: Ik dacht dat het over SVN ging. Deze post heeft dus betrekking op SVN en niet op GIT.

[ Voor 18% gewijzigd door Nick_S op 03-02-2010 14:06 ]

[Sardaukar]

Nick_S schreef op woensdag 03 februari 2010 @ 13:18:
[...]

Je moet alleen niet de working copy met je repository vergelijken, maar met een export. In je workingcopy staan namelijk alle bestanden al twee keer + nog meer metainformatie.

Beetje onduidelijk inderdaad. Ik bedoelde mijn bestanden in de working copy minus de .git directory. En ben je met je opmerking over twee versies van bestanden niet in de war met Subversion?

[Remus]

MLM schreef op woensdag 03 februari 2010 @ 13:08:
Wat ik heel erg irritant aan SVN vind is dat als je een sourcetree met een grote hoeveelheid kleine bestanden wilt in- of outchecken, dat het zo ONTZETTEND langzaam gaat. Ik denk dat het voor elke file een aparte request doet ofzo, en dat de overhead veel te groot is daardoor. Maar goed, ik kan niet zeggen of dat ook het geval is met andere source control systemen

Die vertaging heb ik wel opgemerkt met ssh+svn:, niet met enkel svn: (http: variant eigenlijk nooit gebruikt).

[MBV]

ook met svn: (zelfde als via HTTP maar dan een andere poort vziw) en file: protocollen is performance af en toe bagger. Verzenden van binaries gaat vaak met 5KB/s.

[Soultaker]

Klopt, Subversion is niet supersnel, maar is dat voor de hobbyprojectjes waar de TS het over had een groot bezwaar? Toen ik zelf Subversion gebruikte (ben inmiddels overgestapt op Git) vond ik de performance voor mijn eigen doelen meer dan toereikend.

[Voutloos]

Dit hele topic gaat over dingen die geen bezwaar zijn.

[MBV]

mag ik de voorzichtige conclusie trekken dat alle VCS's die hier genoemd zijn goed genoeg zijn voor de TS? Alles is beter dan geen versiebeheer, met een speciale uitzondering voor SourceSafe
Onder het kopje 'advantages' bij wikipedia:

For small or medium scale development, where multiple versions are not simultaneously supported, its limitations do not cause major problems^{[citation needed]}

En daar is een citation voor nodig, anders gelooft niemand dat

[djc]

Denk dat Mercurial (evt in combinatie met TortoiseHg) wel geschikter is voor een beginnende VCS-gebruiker dan git, dat toch een wat complexere UI heeft. Maar ik zou nu niet meer met SVN gaan beginnen...

[Leftblank]

Verder kun je in het geval van Mercurial gebruik maken van BitBucket.org, welke een gratis private repo aanbied (en unlimited public) met een prettige webinterface, vergelijkbaar met de features van de Git tegenhanger GitHub. Uiteraard is 'n web-repository niet per se noodzakelijk, maar op die manier kun je wel overal je code bewerken en heb je meteen een extra backup, wat nooit kwaad kan.

Ik heb zelf de voorkeur voor HG omdat ik de commandos eenvoudiger vind werken dan die van Git, maar dit is nogal afhankelijk van de persoon natuurlijk - zolang je maar niet voor SVN gaat . Verder kan ik je ook de TortoiseHG/TortoiseGit clients best aanraden op Windows; ze doen hun werk prima en 't scheelt weer een tripje naar de commandline.

[ Voor 14% gewijzigd door Leftblank op 03-02-2010 19:10 ]

[kunnen]

Ik gebruik voor hobbyprojecten gewoon Git op windows, er is zelfs een VS-plugin voor overigens. Daarnaast heb ik een "remote" repository staan in een Dropbox-map (http://www.dropbox.com/) waarmee ik meteen eenvoudig met anderen samen kan werken aan dezelfde repo. (En backups heb)

[Verwijderd]

Bedankt voor alle reakties! Uiteindelijk heb ik toch voor SVN gekozen: Subversion, TurtoiseSVN en de Notepadd++ SVN plugin gedownload en geinstalleerd.

Mijn vraag is nu: wat is de volgende stap? Of beter gezegd: hoe werkt SVN nu precies, want hoewel ik heel veel informatie vind over wat je allemaal wel niet met SVN kunt, zijn er maar weinig eenvoudige begin artikelen te vinden.

De code die ik wil gaan "versioneren" staat in D:/htdocs/cms. Als ik in de directory D:/htdocs ga staan, kan ik via RMB een "create repository here" aanklikken, maar is dat wat ik wil? Met andere woorden: waar creeer ik die repository?

En ook: D:/htdocs/cms is te bekijken via http://localhost/cms. Als ik iets verander in 1 van de (PHP) bestanden in de cms-map, kan ik mijn browser refreshen om het resultaat te bekijken. Als ik een repository maak van D:/htdocs/cms, kan dit dan nog steeds? Met andere woorden, pas ik de bestanden in die map aan als ik ze open in Notepad++ of open ik dan een kopie van dat bestand uit een SVN database?

Een hoop vragen, ik hoop dat iemand mij wat wijzer kan maken

[ Voor 3% gewijzigd door Verwijderd op 04-02-2010 20:19 ]

[muksie]

Je maakt je repository ergens anders aan, bijvoorbeeld in D:/svn/cms

Vervolgens maak je een (tijdelijke) checkout aan, waarbij je mapjes tags/ branches/ trunk/ aanmaakt, en alle al bestaande code toevoegt, bijv. onder trunk/

Dit commit je. Daarna maak je een nieuwe checkout van je repository (van je trunk bijv.) in /htdocs/cms.

En misschien is het handiger om eerst even wat te spelen met het gebruik van subversion voordat je je code er in zet. Zorg iig dat je altijd nog een kopie van je code ergens hebt totdat je svn repository goed werkt.

[ Voor 24% gewijzigd door muksie op 04-02-2010 20:41 ]

[CoolGamer]

Hier staat een redelijke uitleg over hoe je SVN kunt gebruiken. Hier staat in wat alle commando's inhouden en wanneer je welke gebruikt.
http://svnbook.red-bean.com/

[MacWolf]

Zelf zat ik afgelopen week ook te kijken naar een geschikte CVS voor een privé project. Op mijn werk gebruiken we overigens Subversion en dat heeft mij nog geen problemen gegeven. Privé zal ik waarschijnlijk voor Git gaan, gezien er een goede site is (http://www.github.com). Daarnaast stellen ze geen voorwaarden aan je projecten, je kan zelf kiezen voor closed-source, open-source en allerlei variaties. Dit is bijv. niet mogelijk met Google Code (een SVN service), die eisen een open-source licentie. Andere SVN alternatieven die ik gezien heb werken niet naar wens i.c.m. mijn IDE.

[Sardaukar]

MacWolf schreef op donderdag 04 februari 2010 @ 23:41:
Privé zal ik waarschijnlijk voor Git gaan, gezien er een goede site is (http://www.github.com). Daarnaast stellen ze geen voorwaarden aan je projecten, je kan zelf kiezen voor closed-source, open-source en allerlei variaties.

Let erop dat je met een gratis account bij Github alleen open-source projecten mag hosten.

[Sardaukar]

muksie schreef op donderdag 04 februari 2010 @ 20:39:
Je maakt je repository ergens anders aan, bijvoorbeeld in D:/svn/cms

Vervolgens maak je een (tijdelijke) checkout aan, waarbij je mapjes tags/ branches/ trunk/ aanmaakt, en alle al bestaande code toevoegt, bijv. onder trunk/

Dit commit je. Daarna maak je een nieuwe checkout van je repository (van je trunk bijv.) in /htdocs/cms.

Grappig om te zien dat het client-server design van Subversion door deze instructies naar boven komt.

[Verwijderd]

TS, welk OS gebruik je?

[Verwijderd]

Verwijderd schreef op vrijdag 05 februari 2010 @ 19:24:
TS, welk OS gebruik je?

Windows 7 (32 bit), Apache 2.2.14, Subversion 1.6.9

[NC83]

djluc schreef op dinsdag 02 februari 2010 @ 21:48:
Je hebt eigenlijk 2 grote, SVN en GIT. Elk heeft zo zijn eigen voordelen, beetje afhankelijk van of je op Windows of Linux/Mac werkt kan je de keuze bepalen. Over het algemeen werkt SVN op Windows het lekkerste en GIT op de overige platforms. Op beide werkt het echter en vaak is het dan ook een verschil van voorkeur. Bij GIT heb ik nooit echt rechten in hoeven te stellen op lokale machines dus dat lijkt me niet zo'n issue.

Je kan bijvoorbeeld hier eens kijken om een online storage te gebruiken:
http://www.straw-dogs.co....project-hosting-services/

Je hebt dan meteen een back-up van je gegevens op een externe locatie.

als je commercieel gaat moet je daar ook perforce bij rekenen hoor, wat trouwens geloof ik gratis is voor een developer of 2 daarna moet je er voor betalen.

[ Voor 56% gewijzigd door NC83 op 06-02-2010 03:54 ]

[djc]

Sardaukar schreef op vrijdag 05 februari 2010 @ 08:29:
Let erop dat je met een gratis account bij Github alleen open-source projecten mag hosten.

Dit in tegenstelling tot Bitbucket (voor Mercurial), waar je met een gratis account ook een prive-repository mag hosten.

[Kirth]

Ikzelf prefereer Subversion (SVN). Git en Mercurial (HG) heb ik nooit fijn vinden werken. Git onder Windows doet me trouwens vaak als een "second class" gebruiker voelen, want de officiële manier om Git onder Windows te gebruiken is via Cygwin (een library die de Linux-omgeving emuleert). Hoewel ik geloof dat er nu ook al een op MinGw gebaseerde port bestaat.

[Leftblank]

Kirth schreef op dinsdag 09 februari 2010 @ 11:59:
Ikzelf prefereer Subversion (SVN). Git en Mercurial (HG) heb ik nooit fijn vinden werken. Git onder Windows doet me trouwens vaak als een "second class" gebruiker voelen, want de officiële manier om Git onder Windows te gebruiken is via Cygwin (een library die de Linux-omgeving emuleert). Hoewel ik geloof dat er nu ook al een op MinGw gebaseerde port bestaat.

Dat is inderdaad 'n nadeel bij Git, Mercurial is in Python geschreven en draait ook op Windows prima wat 't wel een waardig alternatief maakt voor SVN op Windows. De keus blijft aan jezelf natuurlijk, het feit dat 't een distributed VCS is maakt 't per definitie al wat minder eenvoudig, voordelen geeft 't natuurlijk ook; offline revisies etc in kunnen zien is wel zo prettig qua snelheid.

[Sardaukar]

Kirth schreef op dinsdag 09 februari 2010 @ 11:59:
Ikzelf prefereer Subversion (SVN). Git en Mercurial (HG) heb ik nooit fijn vinden werken. Git onder Windows doet me trouwens vaak als een "second class" gebruiker voelen, want de officiële manier om Git onder Windows te gebruiken is via Cygwin (een library die de Linux-omgeving emuleert). Hoewel ik geloof dat er nu ook al een op MinGw gebaseerde port bestaat.

Officiële manier? Git is prima te gebruiken zonder Cygwin. Ik draai het hier gewoon via de standaard commandline en dat werkt prima. (Windows 7)

Kijk anders naar uitbreidingen als GitExtensions of TortoiseGit als je liever geen gebruikt maakt van de commandline interface.

[BCC]

Kirth schreef op dinsdag 09 februari 2010 @ 11:59:
Git onder Windows doet me trouwens vaak als een "second class" gebruiker voelen

Wat is de laatste keer dat je dat geprobeerd hebt? Want er zijn de laatste tijd hele grote stappen gezet voor Git onder windows. Daarnaast voel ik mij bij windows altijd een second class gebruiker

[bat266]

Misschien wel relevant voor deze discussie, martin fowler heeft er ook iets over te zeggen:
http://martinfowler.com/bliki/VersionControlTools.html

[supakeen]

Mwah,

Ik zie hier iedereen miepen over SVN vs. git, er zijn echter nog andere spelers op de markt.

Het is eigenlijk de 'oude' vcsen versus de 'nieuwe' dvcsen.

Oftewel CVS (die kun je alt meteen doorstrepen), SVN versus git, mercurial, darcs en de reutemeteut. Ik kan je wel zeggen dat mercurial je alle voordelen biedt die git je ook biedt (inclusief staging area, patch queues etc) en dat er een TortoiseHg bestaat voor mercurial.

Oh, en er is natuurlijk nog bazaar (bzr), daarmee kun je elke werkwijze volgen die je maar wil (althans, daar staat het om bekend).

Ik gebruik zelf voornamelijk mercurial, dat komt omdat de open source projecten waaraan ik bijdraag bijna allemaal voor mercurial hebben gekozen. Verder heb ik ze allemaal geinstalleerd staan en heb ik in allemaal wel een projectje of twee

[ Voor 30% gewijzigd door supakeen op 18-02-2010 00:03 ]

[bat266]

ikanobori schreef op donderdag 18 februari 2010 @ 00:00:
Mwah,

Ik zie hier iedereen miepen over SVN vs. git, er zijn echter nog andere spelers op de markt.

...

Dat iedereen miept over git vs svn is denk ik niet helemaal waar. Maar er zit wel een fundamenteel verschil tussen de twee distributed of niet. Elk met zijn eigen voor- en nadelen. Ik denk dat Martin Fowler daar wel zinnige dingen over zegt. Welke tool je daarna kiest hangt helemaal van de requirements, ervaringen standaarden in je eigen organisatie/ project af.

Ik vond vooral de 2 VCS systemen in 1 project wel interressant. Ik weet alleen niet of het de overhead waard is.

[MBV]

Ik vind dat ook wel een interessante gedachte. GIT lokaal om lokaal iets van 'backup', en SVN voor 'de groep'. Als je Eclipse gebruikt is dat weer onzin: die houdt vanaf de laatste commit een lokale geschiedenis bij voor elke save.

[bat266]

Dan mis je wel de lokale experimentele branch die soms handig is. Maar ik moet wel eerst het echt proberen of dat voldoende voordelen biedt t.o.v. eclipse

[MBV]

dan doe je eerst een commit met SVN, ga experimenteren, en als het je niet bevalt kan je naar vanochtend 10:00 teruggaan (toen je experimentje het nog deed) of reverten naar je laatste commit.