Versiebeheer ervaringen?

[bartvb]

Ik heb jaren CVS gebruikt en dat bevalt redelijk. Het is een redelijk minimale en nogal 'ruwe' manier van versiebeheer als je het vergelijkt met de nieuwe systemen. Het probleem is nu het kiezen van een opvolger en dat is nogal lastig, er zijn flink wat alternatieven met allemaal hun eigen voordelen.

Subversion (svn) is een heel erg populair alternatief voor CVS. Het lijkt sterk op CVS maar heeft daardoor ook een aantal beperkingen van CVS (het is gecentraliseerd b.v.). Grootste voordeel van svn is dus dat het vertrouwd terein is (het werkt bijna 100% hetzelfde voor de gebruiker) en er zijn veel tools (GUIs e.d.) voor.

SVK is een gedecentraliseerde versie van SVN, het is als het ware een Perl schil om de basis van SVN heen. Veel makkelijker mergen, mirroren en dus vooral gedecentraliseerd.

Bazaar (bzr) is een soort van 'ultieme' SCM tool maar is nogal lastig in gebruik.

Darcs werkt via de 'Theory of Patches', erg leuk idee, erg simpel in gebruik en ook in opzet, heel flexibel daardoor. Geschreven in Haskell wat het iets minder toegankelijk maakt en waardoor het wat aan de trage kant is bij het gebruik met erg grote repositories.

Dan hebben we ook nog Perforce, Monotone, Mercurial, Aegis, etc, etc.

Het probleem is nu: wat kan ik het beste gebruiken Wat voor een ervaringen hebben jullie? Daarnaast zit ik met een redelijk specifiek probleem:

Ik heb een codebase die van een externe partij komt (noem het even Project A). Deze code is aangepast voor, zeg, 3 klanten. Klant 1, 2 en 3. Nu zijn er aan Project A een aantal features toegevoegd namelijk Feature I, Feature II en Feature II. Klant A gebruikt alleen I en II, Klant B gebruikt II en III en Klant C gebruikt features I en III. Stel nu even dat het ivm licenties e.d. niet mogelijk is om alle klanten dezelfde codebase te geven maar dan met bepaalde features uitgeschakeld.

Hoe ga je dit in hemelsnaam bijhouden? Aan de ene kant heb je de externe code welke je ook nog eens wilt onderhouden. Als je daar een bug in vindt dan wil je die bug fixen, in de code van alle klanten integreren en naar de externe partij sturen die Project A beheert. Verder wil je dat als je een bug fixed in Feature I dat deze fix dan bij zowel klant A en C doorgevoerd wordt. Als bonus zou het helemaal prettig zijn als je Feature I zou kunnen isoleren als patch tov de externe code zodat je deze feature richting externe partij kan sturen of zodat je deze ook bij de nieuwe klant D kan implementeren.

Iemand _enig_ idee hoe je dit op zou kunnen lossen? Ik heb me helemaal suf zitten lezen en iedere keer lijkt er wel weer iets te missen of niet te werken zoals ik het wil in een SCM systeem

[Sybr_E-N]

Misschien is het wel handig op te vertellen in wat voor taal/ platform je aan het programmeren bent? Op mijn werk programmeren we in C# in combi met allerlei andere Microsoft (ontwikkel) tools en aangezien die programma's allemaal handig met elkaar samen kunnen werken, gebruiken wij Visual SourceSafe.

Ik weet niet tot hoever dat daadwerkelijk relevant is, en of het je kan limiteren in bepaalde keuze's voor een pakket.

Mijn eigen ervaring met versiebeheer is eigenlijk subzero

[Boudewijn]

ik ben dan meer SVN fan; goede integratie in Linux.Gratis en goede implementatie die open is (en niet van MS).

Maar idd je eigen platform speelt ook heel erg mee.

[bartvb]

Iek! Visual SourceSafe is geen optie ook al zou ik in C# bezig zijn Het is echt een heel erg flinke uitdaging om positieve verhalen te vinden over VSS Ik heb er een keer serieus naar gekeken (een manager bij een klant had bedacht dat het handig zou zijn als ze op VSS over zouden gaan) maar ik heb echt niet veel positiefs kunnen vinden over VSS terwijl ik toch redelijk m'n best heb gedaan om beide kanten te belichten

Het gaat het hier voornamelijk om PHP code, ik gebruik zelf Linux en OS X voor development. GUIs zijn voor mij niet boeiend maar als er fatsoenlijke GUI tools beschikbaar zijn (bij voorkeur Tortoise achtig) dan is dat zeker wel een pre voor het systeem (ivm met andere developers die niet zonder TortoiseCVS kunnen op het moment).

[ Voor 27% gewijzigd door bartvb op 22-05-2006 22:03 ]

[Super_ik]

ook al naar git gekeken? werkt decentraliseerd.
ikzelf ben een redelijke fan van svn (tortoiseSVN) en gebruikt het zowel onder linux als windows en door elkaar.

[BCC]

bartvb schreef op maandag 22 mei 2006 @ 21:47:
Ik heb een codebase die van een externe partij komt (noem het even Project A). Deze code is aangepast voor, zeg, 3 klanten. Klant 1, 2 en 3. Nu zijn er aan Project A een aantal features toegevoegd namelijk Feature I, Feature II en Feature II. Klant A gebruikt alleen I en II, Klant B gebruikt II en III en Klant C gebruikt features I en III. Stel nu even dat het ivm licenties e.d. niet mogelijk is om alle klanten dezelfde codebase te geven maar dan met bepaalde features uitgeschakeld.
Hoe ga je dit in hemelsnaam bijhouden?

Eeh Branches? Een trunk voor je centrale code base en meerdere branches voor je "add-ons". En dan natuurlijk ook branchen als je een stabiele versie hebt voor Feature A op basis van Core versie X.

Daarnaast ben ik nu bezig met een project dat ontwikkeld wordt in SVN via Trac. Ik vind dit echt een ideale manier. Stukken beter en fijner dan Source safe en CVS. Bij Sourcesafe heb ik ook al meerdere malen database crashes meegemaakt wat niet zo prettig was en zit je met het probleem dat je altijd moet uit-checken om te wijzigen. Dit is vooral met veel coders erg naar. CVS is proven maar oud. SVN wordt ontwikkeld door de ontwikkelaars van CVS en bevalt mij dus tot nu toe erg goed.

[ Voor 7% gewijzigd door BCC op 22-05-2006 22:17 ]

[bartvb]

Wel naar Git gekeken maar dat is zo ongeveer specifiek voor Linux kernel development gemaakt. Schijnbaar nauwelijks geschikt voor een ander model van development dan bij de Linux kernel (waar je 1 'gatekeeper hebt'. Dat is iig wat ik me er van herinner, niet heel veel over Git opgeschreven. Git schijnt iig geen populaire keuze te zijn.

[CaptBiele]

bartvb schreef op maandag 22 mei 2006 @ 22:00:
Iek! Visual SourceSafe is geen optie ook al zou ik in C# bezig zijn Het is echt een heel erg flinke uitdaging om positieve verhalen te vinden over VSS Ik heb er een keer serieus naar gekeken (een manager bij een klant had bedacht dat het handig zou zijn als ze op VSS over zouden gaan) maar ik heb echt niet veel positiefs kunnen vinden over VSS terwijl ik toch redelijk m'n best heb gedaan om beide kanten te belichten

Ik heb zelf goede ervaringen met de oude versie, maar ik hoor ook wel eens minder positieve verhalen inderdaad. Maar ik denk dat de nieuwe versie toch echt wel goed in elkaar zit.

[djc]

BCC schreef op maandag 22 mei 2006 @ 22:03:
Daarnaast ben ik nu bezig met een project dat ontwikkeld wordt in SVN via Trac.

Ik ben ook een groot fan van deze combi (ik doe zelfs wat development voor Trac, af en toe).

That said, de gedistribueerde variant is in opkomst en ziet er erg interessant uit, wat mij betreft met name bzr, darcs en mercurial (niet noodzakelijkerwijs in die volgorde). Als je extreem gehecht bent aan overrijpe stabiele software zou ik sowieso voor SVN gaan, in andere gevallen kan je misschien wat testen met de gedistribueerde VC-software om te kijken of het je bevalt.

[MSalters]

Er zijn twee of drie simpele regels met versiebeheer:
0. Elk product is beter dan geen versiebeheer.
1. VSS is het slechtste product
2. CVS is het slechtse product van de serieuze producten.

Serieus is in dit verband: bestand tegen 10+ gebruikers, Client/Server of betere netwerk support, geen random verlies van files.

Het grootste voordeel van VSS is dat de UI zinnig is, de reden waarom het nog steeds gebruikt wordt. Simpele taken zijn namelijk simpel. (Moeilijke dingen hoefden ze ook niet met hun UI te doen. Dat kan VSS namelijk ook niet, maar dat is muggeziften)

[JKVA]

Ik vind SVN ook wel leuk. Leuke shell clients voor te krijgen. Alleen jammer dat het nog niet in Eclipse zit, waar ik toch eigenlijk voor 100% mee werk, net als vele Java'ers.

Dan valt de keuze automatisch op CVS........

[bartvb]

Eehm, er zijn perfecte SVN plugins om SVN in Eclipse te krijgen. Zelfde met Darcs IIRC.

Branches is idd waar ik op uit kom met de meeste systemen (iig dingen als CVS, SVN, SVK). Alleen zit ik dan met nogal ingewikkelde relaties.

Een vendor branch met de externe code
Een branch met feature I
Een branch met feature II
Een branch met feature III
Een branch met feature I en III voor klant A
idem voor klant B en C

Dat wordt allemaal nog een stuk lastiger als er features bij komen en ik vraag me ook af of je een branch afhankelijk kan maken van b.v. 3 andere branches (vendor + feature I & III bijvoorbeeld)?

[grhmpf]

JKVA schreef op woensdag 24 mei 2006 @ 21:04:
Ik vind SVN ook wel leuk. Leuke shell clients voor te krijgen. Alleen jammer dat het nog niet in Eclipse zit, waar ik toch eigenlijk voor 100% mee werk, net als vele Java'ers.

Dan valt de keuze automatisch op CVS........

http://subclipse.tigris.org
http://www.polarion.org/i...erview&project=subversive

Subclipse ken ik en bevalt me prima.

[grhmpf]

bartvb schreef op woensdag 24 mei 2006 @ 21:19:
Eehm, er zijn perfecte SVN plugins om SVN in Eclipse te krijgen. Zelfde met Darcs IIRC.

Branches is idd waar ik op uit kom met de meeste systemen (iig dingen als CVS, SVN, SVK). Alleen zit ik dan met nogal ingewikkelde relaties.

Een vendor branch met de externe code
Een branch met feature I
Een branch met feature II
Een branch met feature III
Een branch met feature I en III voor klant A
idem voor klant B en C

Dat wordt allemaal nog een stuk lastiger als er features bij komen en ik vraag me ook af of je een branch afhankelijk kan maken van b.v. 3 andere branches (vendor + feature I & III bijvoorbeeld)?

In de eerste plaats moet je denk ik per "release" per klant al een branch hebben omdat ze andere features bevatten. Wat je zou kunnen doen met subversion is met externals werken. Subversion kan directories elders in de repository uitchecken op het moment dat je een project uitcheckt. Voorbeeld:

Je hebt project A met een dir featureA. Als je featureA nu defineert als een "external" dan kan je die external als apart project in de repository zetten en op developen. Bij het uitchecken van project A zal feature A gevuld zijn met de source van dat aparte projectje. Een soort van links dus.

Voorwaarde is dat je dus een soort van common codebase hebt met "plugin code" die je per klant erin duwt. Voordeel is dat je klant features dan kan hergebruiken.

[BCC]

bartvb schreef op woensdag 24 mei 2006 @ 21:19:
Eehm, er zijn perfecte SVN plugins om SVN in Eclipse te krijgen. Zelfde met Darcs IIRC.

Branches is idd waar ik op uit kom met de meeste systemen (iig dingen als CVS, SVN, SVK). Alleen zit ik dan met nogal ingewikkelde relaties.

Dat wordt allemaal nog een stuk lastiger als er features bij komen en ik vraag me ook af of je een branch afhankelijk kan maken van b.v. 3 andere branches (vendor + feature I & III bijvoorbeeld)?

Dit is een probleem van je code wat geen enkel versioning systeem voor je gaat oplossen. Het is verstandiger je features zo modulair te maken dat je dus feature I, II en III als "plugins" gaan werken op je centrale core. Deze plugins en de code gooi je dan in verschillende branches. Nieuwe features vormen dan geen enkel probleem en alle klanten kunnen met de laatste versies van hun features draaien.

[ Voor 8% gewijzigd door BCC op 24-05-2006 21:33 ]

[BCC]

JKVA schreef op woensdag 24 mei 2006 @ 21:04:
Ik vind SVN ook wel leuk. Leuke shell clients voor te krijgen. Alleen jammer dat het nog niet in Eclipse zit, waar ik toch eigenlijk voor 100% mee werk, net als vele Java'ers.
Dan valt de keuze automatisch op CVS........

Die zijn er zeker wel. Daarnaast zijn er veel mensen die de shell clients een stuk overzichtelijker vinden dan een plugin (ik ben daar zeker één van). En die 5 commando's voor een svn workcycle zijn ook nog wel een keer uit je hoofd te leren: svn up, svn add, svn delete, svn resolved, svn ci

[ Voor 3% gewijzigd door BCC op 24-05-2006 21:51 ]

[KnoppenSpook]

niet in Eclipse zit, --> Kijk eens naar SubClipse -> http://subclipse.tigris.org/

[whoami]

Als je een UI wil die lijkt op die van VSS, een betrouwbare repository, etc... dan kan je eens naar SourceGear's Vault kijken.
Vault integreert perfect in VS.NET, maar dat is natuurlijk niet belangrijk als je VS.NET niet gebruikt (wat je dus ook niet doet).

SVN heb ik ook eens bekeken, maar ik moest van her en der plug ins gaan verzamelen, dat ik het maar opgegeven heb.

Wellicht dat dit trouwens ook nog een handig artikel is.

[djc]

BCC schreef op woensdag 24 mei 2006 @ 21:32:
Dit is een probleem van je code wat geen enkel versioning systeem voor je gaat oplossen. Het is verstandiger je features zo modulair te maken dat je dus feature I, II en III als "plugins" gaan werken op je centrale core. Deze plugins en de code gooi je dan in verschillende branches. Nieuwe features vormen dan geen enkel probleem en alle klanten kunnen met de laatste versies van hun features draaien.

En anders kan het werken om te werken met changeset ranges die je merged van branch naar branch. svnmerge.py, dat je volgens mij ergens bij SVN kunt krijgen, helpt erbij om dit makkelijk te maken (momenteel wordt er door het Subversion project gewerkt aan plannen om 'merge tracking' te ondersteunen, zodat je makkelijk kunt bijhouden welke revision ranges je waar al gemerged hebt).

[bartvb]

Merge tracking is (voor zover ik het begrepen heb) een van de voordelen van het gebruik van SVK, SVK weet precies welke changesets je al gemerged hebt van welke branch. Het is me alleen nog niet helemaal duidelijk of je changes van twee branches automatisch kan mergen naar 1 andere branch.

[JKVA]

KnoppenSpook schreef op woensdag 24 mei 2006 @ 22:58:
niet in Eclipse zit, --> Kijk eens naar SubClipse -> http://subclipse.tigris.org/

@KnoppenSpook en anderen: Het is idd als plugin te verkrijgen, maar het zou fijn zijn als het default al in Eclipse zat. Nu ben je een eeuwigheid plugins aan het zoeken/installeren; tijd die je ook aan ontwikkelen kunt besteden.

Dat is niet zo zeer mijn gedachte, maar wel de gedachte binnen onze organisatie, waardoor nog niet voor SVN gekozen is in de nieuwe straat. Ik heb niks te willen... (sniksnik)

[st0p]

ik geef dit topic even een grote schop

ik ben al een tijd op zoek naar een cvs wat met name geschik is voor de hobby-programmeur... waar het met name om gaat is dat ik gewoon op één pc mijn eigen code voor mijn eigen projecten in kan checken. er werken geen anderen aan dezelfde code en ik heb geen zin in al die systemen waarbij je met servers/clients werkt, ik snap het nut ervan maar voor mij is het overkill. nu heb ik zeg maar verschillende mappen met elk een "versie" van het project. dit zoekt niet handig en gaat toch aardig wat diskruimte opeisen (alhoewel dat niet zo'n probleem is). een GUI erbij zou leuk zijn maar hoeft niet perse. mijn zoektochten op google hebben tot op heden niks opgeleverd, heeft iemand tips?

[eamelink]

Ik vraag me af waar je op zoekt als je bij Google geen versiebeheersysteem kan vinden terwijl je nauwelijks eisen hebt . Subversion is waarschijnlijk prima voor al je doelen

[st0p]

ik heb net uitgebreid naar subversion zitten kijken, maar het is nog steeds server/client based (of ik zie iets helemaal over het hoofd?)... ik begrijp wel dat als er meerdere mensen aan één project werken dat je niet aan zo'n architectuur ontkomt maar ik heb gewoon weinig zin om nog een extra achtergrond service te hebben draaien.

nou moet ik wel zeggen dat dit inspiratie oplevert om een eigen tool te schrijven

[eamelink]

Je kunt gewoon lokale repositories gebruiken, dan heb je geen server nodig voor SVN.

[kenneth]

st0p schreef op zaterdag 31 maart 2007 @ 19:39:
ik heb net uitgebreid naar subversion zitten kijken, maar het is nog steeds server/client based (of ik zie iets helemaal over het hoofd?)... ik begrijp wel dat als er meerdere mensen aan één project werken dat je niet aan zo'n architectuur ontkomt maar ik heb gewoon weinig zin om nog een extra achtergrond service te hebben draaien.

nou moet ik wel zeggen dat dit inspiratie oplevert om een eigen tool te schrijven

Is dat niet echt zwaar overkill? 'n Vierkant wiel uitvinden terwijl het ronde wiel al heel wat jaartjes ronddraait?
Zoals eamelink zegt, kan je ook lokale repositories gebruiken, maar je heb ook wel 'n beetje koudwatervrees voor client/server heb ik het idee ... het is niet alsof dat ding op de achtergrond draait met 256MB geheugen en 20% CPU usage ofzo. Iedere bak waar je op kan ontwikkelen, kan je zo'n service draaien, dat gaat je echt niet opvallen ofzo ...

[chris]

Ik heb zelf het meest ervaring met Subversion. We draaien hier een groot project (ik gok z'n 30 full-time developers), we zijn bij een flink hoge revisie en het is nog steeds lekker snel en betrouwbaar. Er is veel integratie met Development Tools, Windows Explorer, etc. Ik gebruik zelf het liefst svn vanaf de commandline icm met "svnvimdiff".

Voor m'n eigen (kleinere) projecten gebruik ik darcs. Wat ik daar echt ontzettend relaxed aan vindt, is dat je kan cherrypicken: voor je commit, kan je per file kiezen welke changes je commit, met subversion kan je alleen kiezen of je een file wel of niet commit. Ook cool is dat het distributed is, en dat de manier om je changes op te sturen erg lekker werkt. En tot slot is het geschreven in Haskell, wat de kans verhoogt dat het stabiel is en minder bugs heeft.

Voor een echt groot project zou ik subversion aanraden: het is open source, werkt op alle platformen, goede integratie, etc. Voor een hobbyproject zou ik ze gewoon allemaal uitproberen. En dan niet voor een uurtje, maar voor een paar weken, zodat je echt een gevoel krijgt wat de voordelen zijn.

[The - DDD]

JKVA schreef op donderdag 25 mei 2006 @ 16:06:
[...]


@KnoppenSpook en anderen: Het is idd als plugin te verkrijgen, maar het zou fijn zijn als het default al in Eclipse zat. Nu ben je een eeuwigheid plugins aan het zoeken/installeren; tijd die je ook aan ontwikkelen kunt besteden.

Dat is niet zo zeer mijn gedachte, maar wel de gedachte binnen onze organisatie, waardoor nog niet voor SVN gekozen is in de nieuwe straat. Ik heb niks te willen... (sniksnik)

Wat een stelletje azijnzeikerd daar dan zeg. Hoe moeilijk is het om een zooitje plugins te deployen? Het hoeft niet via Eclipse UI zelf. Gewoon copy pasten is al voldoende.

Zelf heb ik in een subversion repo al mijn documenten zitten. Deze repository wordt regelmatig een nette backup van gemaakt. Zo zijn mijn lieve documentjes en echt belangrijke spulletjes altijd veilig. *aai*

Wat betreft de CVS/SVN discussie. Als je twijfelt tussen CVS en SVN, dan is de keuze simpel. Scheit aan CVS. Als je absoluut geen client server wilt, maar wel enigzins spullen uit wil kunnen wisselen. Dan kun je iets als Darcs overwegen... Waar ook een vrij goede Eclipse plugin voor te krijgen is. http://eclipsedarcs.org/ (Aangezien het er op lijkt dat er gezocht wordt naar een oplossing voor Eclipse.)

Overigens Zul je met Eclipse altijd hebben dat je een samenraapsel van plugins moet samenstellen. De Eclipse IDE is van zich zelf namelijk nogal kaal. het resultaat kun je gewoon zippen en deployen door even uit te pakken. net als Eclipse zelf.

[ Voor 38% gewijzigd door The - DDD op 02-04-2007 19:01 ]

[djc]

Als je voor een DVCS gaat zou ik Mercurial bekijken, daar hoor ik het meeste positieve verhalen over (en is dus zonder client-server-verhaal).

[The - DDD]

Hmm, nog eentje om uit te proberen. Heb al met darcs en svk zitten prutsen.


Edit:

Waarom zijn die distributed dingen in nogal afwijkende talen geschreven?

SVK -> Perl
Mercurial -> Python
darcs -> Haskell

[ Voor 48% gewijzigd door The - DDD op 03-04-2007 19:22 ]

[BCC]

The - DDD schreef op dinsdag 03 april 2007 @ 19:20:
Hmm, nog eentje om uit te proberen. Heb al met darcs en svk zitten prutsen.


Edit:

Waarom zijn die distributed dingen in nogal afwijkende talen geschreven?

SVK -> Perl
Mercurial -> Python
darcs -> Haskell

Het is maar wat je afwijkend vindt. Perl en Python zijn volgens mij erg normaal en beschikbaar op elke *NIX bak.

[ Voor 3% gewijzigd door BCC op 04-04-2007 18:25 ]

[kenneth]

Mwoh, niet bij default dacht ik zo. Wijdverspreid is het zeker, en makkelijk te krijgen ook.

Ik denk dat hij met afwijkend bedoelt dat er weinig SCC's worden geschreven in scripttalen of functionele talen. Meestal is het toch oldskool 3GL wat er gebruikt wordt ...

[Janoz]

st0p schreef op zaterdag 31 maart 2007 @ 19:39:
ik heb net uitgebreid naar subversion zitten kijken, maar het is nog steeds server/client based (of ik zie iets helemaal over het hoofd?)... ik begrijp wel dat als er meerdere mensen aan één project werken dat je niet aan zo'n architectuur ontkomt maar ik heb gewoon weinig zin om nog een extra achtergrond service te hebben draaien.

nou moet ik wel zeggen dat dit inspiratie oplevert om een eigen tool te schrijven

Subversion is geen achtergrond process (of iig nauwelijks). Het is een applicatie die start zodra iemand iets met de repository wil doen. Het enige dat het inneemt is schijfruimte. Ik heb hier lokaal op mijn thuisservertje (was eerder een P1, nu een P2) een repository. Wanneer je hiermee verbind wordt gewoon verbonden via ssh en wordt het svn commando uitgevoerd. Load is er dus alleen wanneer iemand de repository bevraagd, voor zover je uberhaupt over load kunt spreken.

Nadeel van SVN vind ik trouwens dat je altijd met directories werkt, ook voor je tags en branches. Erg vervelend wanneer je de hele boel opgezet hebt om vervolgens tot de ontdekking te komen dat je eigenlijk alles in een directory trunc had moeten zetten .

[4of9]

st0p schreef op zaterdag 31 maart 2007 @ 17:53:
ik geef dit topic even een grote schop

ik ben al een tijd op zoek naar een cvs wat met name geschik is voor de hobby-programmeur... waar het met name om gaat is dat ik gewoon op één pc mijn eigen code voor mijn eigen projecten in kan checken. er werken geen anderen aan dezelfde code en ik heb geen zin in al die systemen waarbij je met servers/clients werkt, ik snap het nut ervan maar voor mij is het overkill. nu heb ik zeg maar verschillende mappen met elk een "versie" van het project. dit zoekt niet handig en gaat toch aardig wat diskruimte opeisen (alhoewel dat niet zo'n probleem is). een GUI erbij zou leuk zijn maar hoeft niet perse. mijn zoektochten op google hebben tot op heden niks opgeleverd, heeft iemand tips?

Sourcegear vault is geloof ik voor een single home user gratis. En heeft een gui en werkt erg prettig. Wij gebruiken het nu een paar maanden en zijn zeer tevreden. (zie ook het artikel dat Whoami gepost heeft, daar heb ik veel van opgestoken)

[djc]

kenneth schreef op woensdag 04 april 2007 @ 22:03:
Mwoh, niet bij default dacht ik zo. Wijdverspreid is het zeker, en makkelijk te krijgen ook.

Ik denk dat hij met afwijkend bedoelt dat er weinig SCC's worden geschreven in scripttalen of functionele talen. Meestal is het toch oldskool 3GL wat er gebruikt wordt ...

Volgens mij komen de meeste Linux-distributies wel met Perl en/of Python, hoor. Ook omdat veel systeem-scripts geschreven zijn in zo'n taal. Bij Gentoo heb je bijvoorbeeld sowieso Python nodig voor Portage, bij Fedora dacht ik ook voor yum (of is dat SuSE?).

En het voordeel van schrijven in een scripttaal is natuurlijk dat je veel concepten wat natuurlijk kan uitdrukken, dat je veel minder code hoeft te onderhouden en dat het ontwikkelen daardoor minder tijd kost.

Als je overigens toch aan de evaluatie slaat zou ik ook nog bazaar-ng bekijken (ook in Python).

[kenneth]

Linux != *NIX !!

Of beter: slechts 'n subset ervan.

[ Voor 54% gewijzigd door kenneth op 05-04-2007 13:05 ]

[BCC]

Janoz schreef op woensdag 04 april 2007 @ 22:08:
[...]
Nadeel van SVN vind ik trouwens dat je altijd met directories werkt, ook voor je tags en branches. Erg vervelend wanneer je de hele boel opgezet hebt om vervolgens tot de ontdekking te komen dat je eigenlijk alles in een directory trunc had moeten zetten .

Ten eerste is het niet maken van een trunk zeker niet strikt noodzakelijk (wel erg slim) en dus een beetje een beginnersfout (je hebt je snv niet slim opgzet).

Ten tweede is het eenvoudig op te lossen door alsnog een trunk aan te maken en je bestaande codebase daar naartoe te svn copy-en.

Ten derde is het trunk .

[Janoz]

Klopt. Het is een beginnersfout, maar ik kwam er pas achter toen ik wilde taggen en mergen. Was het zo snel niet in de verschillende tutorials tegen gekomen (of zeer waarschijnlijk glad overheen gelezen)

Zal binnenkort de boel naar trunk moven

[The - DDD]

Janoz schreef op woensdag 04 april 2007 @ 22:08:
[...]


Subversion is geen achtergrond process (of iig nauwelijks). Het is een applicatie die start zodra iemand iets met de repository wil doen. Het enige dat het inneemt is schijfruimte. Ik heb hier lokaal op mijn thuisservertje (was eerder een P1, nu een P2) een repository. Wanneer je hiermee verbind wordt gewoon verbonden via ssh en wordt het svn commando uitgevoerd. Load is er dus alleen wanneer iemand de repository bevraagd, voor zover je uberhaupt over load kunt spreken.

Nadeel van SVN vind ik trouwens dat je altijd met directories werkt, ook voor je tags en branches. Erg vervelend wanneer je de hele boel opgezet hebt om vervolgens tot de ontdekking te komen dat je eigenlijk alles in een directory trunc had moeten zetten .

Mwoah, gewoon mv-en.

In de root van je working copy gaan staan:

code:

# svn mv * trunk/
# svn mkdir branches/
# svn mkdir tags/
# svn ci -m "Ik ben een verschrikkelijke zut want ik was te lui om de documentatie te lezen, maar nu weet ik beter. Alles gaat nestjes in een trunk dir. :p"