[CVS] Hoe werkt CVS?

[bodiam]

Intro
Beste allen, aub niet meteen dit topic sluiten, ik weet best hoe google werkt, ook hoe cvshome werkt, en ook hoe nieuwsgroepen werken. Wat ik echter niet weet is hoe op verstandige manier met meerdere personen kunt werken met CVS.

Uiteraard hebben we meerdere dingen geprobeerd. Release tags, branches, met z'n allen op de root branch, maar niets werkt lekker.


Werkmethode
Wat we op dit moment doen is als volgt:



Oftwel: er is 1 hoofdbranch. Hierop werkt niemand. Iedereen heeft zijn eigen branch, waarop iemand op elk moment een commit kan doen, zonder iemand anders dwars te zitten (zeker als iedereen ergens anders aan werkt, en code nog niet stabiel is, is dit handig). Deze branches worden niet live gezet, enkel de main branch wordt live gezet. Om dit te doen, moeten eerst de updates van de main branch naar de branch gemerged worden van degene die iets live gaat zetten, waarna getest kan worden. Na testen, wordt alles richting de main branch gecommit, en zou het 'klaar' moeten zijn.

De commando's die we daarvoor uitvoeren zijn dit:

code:

cvs update -A                              [wissel naar de trunk]
cvs update -j erik                         [merge wijzigingen naar de trunk]
[resolve conflicts, test alles, etc]
cvs commit -m "Merged from branch to trunk"
cvs update -r erik                         [wissel terug naar dee branch]
cvs tag RC_1_0_0_last_merge                [onthoud de laatste merge point] schrijft tag op branch
[merge is klaar]

(Deze stappen zijn nog onjuist ook, omdat de tag op de eigen boom komt, ipv de main branch.)

Nadelen
Aan deze oplossing (als het er 1 is) zitten wat nadelen. 1 daarvan is dat het lastig is om te mergen van de main branch naar je eigen branch. Door een hoop mensen wordt dit ook niet aanbevolen. Verder zijn er wat issues met het verder werken na een commit richting de branch. Uiteraard willen we terug in de tijd kunnen, om een commit moment uit te checken, een bug te fixen, en de fix te mergen met de main branch. Maar dit lukt niet helemaal, waardoor we op dit moment steeds een nieuwe boom splitsen.

code:

creating a new branch: cvs rtag -r Tagname -b Branchname my_module
 eg: cvs rtag -r start -b erik platform

Vraag
Wat ik me nu afvraag is het volgende:

Hoe zorg ik er voor dat:
1) We met meerdere mensen tegelijkertijd aan hetzelfde project kunnen werken?
2) We terug in de tijd kunnen om 'dingen' te fixen?
3) Deze fixes weer samenvoegen met alle andere code?

Oftwel: hoe werken jullie met CVS, en welke commando's gebruiken jullie daarvoor?

Alvast bedankt voor de hulp!

[JayVee]

Wij gebruiken Subversion, maar het principe is natuurlijk hetzelfde.

1.) Het is volgens mij echt wel de bedoeling dat iedereen in de trunk werkt. Pas op het moment dat je code waar andere mensen gebruik van maken radicaal gaat veranderen (rewrite, API change) maak je een branch zodat jij en andere mensen zo lang uit elkaar kunnen werken totdat alles een beetje stable is.

2.) Zijn we nu net mee bezig. De opgeleverde tag (1.02) had nog een bugje. We hadden echter al een paar grote (en ongeteste!) veranderingen in de trunk (root) doorgevoerd dus konden we die bugfix niet in de trunk verrichten.
Ik heb toen van die 1.02 tag een branch gemaakt (copy). Daar wordt de bug gefixt en die wijzigingen mergen we dan later terug in de trunk. Weet nog niet precies hoe ik dat ga doen, maar ik denk dat het automatisch wel goed gaat.

//edit
Als ik het goed begrijp willen jullie in de trunk altijd een werkende (en eigelijk bugvrije) versie hebben. Volgens mij gaat dat niet werken (of iedereen moet zijn eigen code voor de commit heel erg goed testen etc...). Daar heb je tags voor. Als je klaar bent met features erin zetten ga je alles goed testen en maak je een kopie naar een tag. Van die tags weet (of hoop) je dan dat ze goed zijn.

[ Voor 20% gewijzigd door JayVee op 04-01-2005 14:05 ]

[bodiam]

JayVee schreef op dinsdag 04 januari 2005 @ 14:02:
Wij gebruiken Subversion, maar het principe is natuurlijk hetzelfde.

//edit
Als ik het goed begrijp willen jullie in de trunk altijd een werkende (en eigelijk bugvrije) versie hebben. Volgens mij gaat dat niet werken (of iedereen moet zijn eigen code voor de commit heel erg goed testen etc...). Daar heb je tags voor. Als je klaar bent met features erin zetten ga je alles goed testen en maak je een kopie naar een tag. Van die tags weet (of hoop) je dan dat ze goed zijn.

Ik heb je andere 2 punten even verwijderd, omdat dit heel goed beschrijft wat we willen. Ik (we) willen inderdaad een bugvrije, stabiele branch hebben. De veranderingen die we maken zijn meestal vrij extreem (een aardige refactoring, een keer aan naamsverandering ondergaan waardoor 4000 html files aangepast worden, van een 1 op 1 relatie naar 1 op n gaan qua domain objecten, nouja, in ieder geval vrij grote aanpassingen per keer). Iets live zetten gebeurt ook niet iedere week, maar eerder eens in de 2 maanden. Wijzigingen zijn dus vaak nogal groot. Om daarom geen last van elkaar te hebben, zou ik toch graag die manier met meerdere branches hebben, vooral omdat mijn collega en ik een totaal andere werkwijze hebben (ik commit elk uur, hij bijv alleen als het 30 keer getest is).

[Creepy]

Aan je werkwijze te zien (iedereen z'n eigen brance) zou je veel makkelijker met een arch, bitkeeper, perfoce o.i.d. aan de slag kunnen gaan i.p.v. CVS.
Daarbij is het mergen tussen branches echt geen probleem (in bijv. bitkeeper een standaard actie ).

Je overige 3 vragen zijn wat mij betreft standaard "CVS" zaken. Uitchecken van files lijkt me duidelijk, iedereen kan zijn of haar eigen wijzigingen committen naar de main branch of eigen branch en met tools als diff kan je weer patches maken om zo de mainbranch aan te passen (en daarna weer te committen )

Verder: wat is nu precies je probleem met CVS? Oudere versies terughalen is een vrij standaard actie lijkt me zo

Daarnaast roep je dat "het niet helemaal lukt". Kan je dat wat precieser aangeven wat er niet lukt, wat er niet lekker werkt etc?

[bodiam]

Creepy schreef op dinsdag 04 januari 2005 @ 14:15:
Aan je werkwijze te zien (iedereen z'n eigen brance) zou je veel makkelijker met een arch, bitkeeper, perfoce o.i.d. aan de slag kunnen gaan i.p.v. CVS.
Daarbij is het mergen tussen branches echt geen probleem (in bijv. bitkeeper een standaard actie ).

Dit zijn paketten waar ik nog niet eerder van gehoord heb. Ik dacht dat CVS 'de' tool was om Concurrent Development te doen, inclusief mergen, versiebeheer, etc.

Je overige 3 vragen zijn wat mij betreft standaard "CVS" zaken. Uitchecken van files lijkt me duidelijk, iedereen kan zijn of haar eigen wijzigingen committen naar de main branch of eigen branch en met tools als diff kan je weer patches maken om zo de mainbranch aan te passen (en daarna weer te committen )

Het uitchecken van files is ook geen probleem, dat heb ik ook niet beweerd. Zoals je zegt is naar de main branch toe geen probleem. Het omgedraaide echter wel. Met een cvs update -A, gevolgd door een cvs update -j 'branchnaam' merge je een branch naar main. Andersom is praktisch onmogelijk.
(Overigens klinkt jouw werkwijze ook wel vrij omslachtig, of zie ik dat verkeerd?)

Verder: wat is nu precies je probleem met CVS? Oudere versies terughalen is een vrij standaard actie lijkt me zo

Dat is geen probleem. Alleen het terughalen, aanpassen, en de wijziging zo committen dat iedereen deze update krijgt, dat is wel een probleem. Een mogelijke oplossing zou zijn om voor iedere fix een aparte branch te maken, maar dit genereert een hoop branches.

Daarnaast roep je dat "het niet helemaal lukt". Kan je dat wat precieser aangeven wat er niet lukt, wat er niet lekker werkt etc?

Nee.

Okee, iets uitgebreider: nee, dat kan ik niet. Op dit moment gaan we vrij standaard om met CVS, en toch heb ik op dit moment weer een X aantal fouten, zoals meldingen als "cvs server: nothing known about <filename>", "File: no file header.www.versatel.nl.js Status: Entry Invalid", bestanden in de CVS attic waardoor andere mensen bij een update deze files niet krijgen, etc.

Ik geloof heilig in CVS, maar we krijgen steeds onverklaarbare rare effecten in CVS. Ongetwijfeld omdat wij iets fout doen, en daarom ook dit topic. Ik heb nu 4 keer CVS opnieuw ingericht, en dat ben ik nu wel een beetje zat. Ik vroeg me daarom af hoe andere mensen er mee werken, en wat wij nou precies verkeerd doen.

(btw, als ik zometeen een nog wat concreter voorbeeld kan geven, zal ik het meteen laten weten.)

[ Voor 3% gewijzigd door bodiam op 04-01-2005 14:45 ]

[JayVee]

Je zegt dat je heilig in CVS geloofd...
Kijk eens naar Subversion. CVS is weliswaar de standaard, heeft echter een aantal vervelende nadelen (niet 'echt' kunnen renamen van bestanden bijvoorbeeld). De makers van Subversion hebben als doel een beter CVS te maken.

[EfBe]

een goed sourcecontrol systeem begint bij het goed organiseren van wat iedereen doet. Zonder dat ben je veel tijd kwijt aan het oplossen van merge conflicts en andere narigheid. Dit komt omdat het niet echt verstandig is dat 2 of meer mensen in dezelfde file gaan zitten wroeten: laat 1 persoon beide wijzigingen doen, kan de ander met andere zaken bezig.

Verder zou ik geen byte in CVS stoppen, het systeem is simpelweg niet robuust genoeg. Atomic checkins zijn een must en het renamen van een file is bv al een hell on earth (en levert hachelijke situaties op soms, zie de mono mailing list van een tijdje terug)

Subversion heeft een zeer goede documentatie waarin goed wordt uitgelegd wat een aantal scenario's zijn. Uitgangspunt is ALTIJD dat verreweg de meeste code die iedere developer gebruikt 'shared' is, en men wijzigingen aanbrengt in de trunk en branched op module niveau.

[bodiam]

Heilig in geloven is iets anders dan het waarderen of zeggen dat het een goed product is. Ik geloof alleen niet dat het zo slecht is als dat ik denk dat het is.

EfBe, wat zijn in jouw context modules? Ik programmeer in Java aan een redelijk groot platform. Check ik een deel niet uit, dan werkt er niets. Ik kan geeneens compileren. Ook al zou het compileren, dan zou het nog niet nuttig zijn omdat ik bepaalde functionaliteit zou missen. Of is dit niet wat je bedoelt met branchen?

Hoe zou jij op moduleniveau je code aanpassen dan? En hoe zorg je dat als je wijzigingen in de trunk krijgt van meerdere developers, dat je toch altijd elk moment live kunt gaan?

[MSalters]

CVS is wel degelijk robuust. Wat het claimt te doen, doet het. Alleen, EfBe heeft wel helemaal gelijk als hij zegt dat CVS essentiele features mist, en flexibiliteit. Versioning Systemen in het algemeen werken het best, als je ze op de standaard manier gebruikt, en CVS is in deze extreem. Of je doet het op de CVS manier, of je hebt diepe ellende. TS doet het niet op de conventionele manier, en merkt dat dus.

De CVS manier is dat je stabiele versies aangeeft met een tag, onderhoud doet op een branch, en development op de main trunk. Als je iets anders wil, het is open source. (aka My way or the highway )

[alienfruit]

Ik heb nog nooit gesnapt hoe CVS/source control systemen werken, het nut van promotion states, states, tags, views, labelsn branches, audit logs heel de mik mak. Het is me al meerdere keren uitgelegd maar op een of andere manier is het gewoon wazig, chekc deze uitleg bijvoorbeeld:

This is a pretty broad question. Labeling is a very important thing to
"really get" and so I'll start there.

Say you have a bunch of files, a,b,c and you check them into starteam as you
are developing them. Each checkin creates a new revision. Labels, in my
way of thinking, are like a rope to tie together specific revisions of items
(files).

Most common usage is to, as I would say, "label all files as of now". For
example,
a0----a1----a2--a3--a4----------------a5--a6---|
b0------------------------b1---b2----------------|
c0---c1-------------------------------c2---c3----|

If the "|"s represent a view label I just created as-of the current
configuration, then my label "ties together" a6, b2, and c3.

a0----a1----a2--a3-|-a4----------------a5--a6---
b0------------------|------b1---b2----------------
c0---c1-------------|------------------c2---c3----

In this example, a view label that I created previously includes a3, b0 and
c1. If I go and checkout current configuration, I get a6, b2, and c3, but
if I checkout my labeled configuration, then I get a2, b0, and c1.

Now, let's suppose that the above diagrams represent version 1 and version 2
of my software. Then the label in the top diagram would probably be named
something like "V2" while the second, older configuration would probably be
named something like "V1". I'll show them together thus...

a0----a1----a2--a3- (V1) -a4----------------a5--a6--- (V2)
b0------------------ (V1) ------b1---b2---------------- (V2)
c0---c1------------- (V1) ------------------c2---c3---- (V2)

Now, a picture like this makes it easy to visualize, "What if I needed to
make a V1.1 that includes b2, but not a4?" You can "see" it like this...

a0----a1----a2--a3- (V1.1) -a4----------------------a5--a6--- (V2)
b0------------------------------b1- (V1.1) --b2---------------- (V2)
c0---c1------------- (V1.1) ------------------------c2---c3---- (V2)

...and in StarTeam, this is called "attaching a label" to the newer
revision, b1. By the way, V1 is still there, but it gets harder to draw the
diagram if I try to show it.

So, there's some label fundamentals for you.

In my shop, I create a "as-of-now" view label (current configuration) just
at the time I am going to run a build. I then checkout from that label to
the build machine and begin compiling. Thus, checkins can continue while a
build runs without confusing the issue of whta checkin made it or didn't.
Anything before the label made it. Anything after didn't.

Is this helping?

Tekst geschreven door David H.

Nou ik snap hier dus echt de ballen van

[Verwijderd]

Dat komt omdat het brak uitgelegd is .

Als je een repository labelt dan neem je als het ware een snapshot van het repository zoals het er op dat moment uit ziet, en je hangt daar een naam aan (vaak met een versienummer erin, want dat is in de toekomst makkelijk terugvinden).

Waarom is dat nuttig? Nou, omdat je aan een bepaalde release van je software bijvoorbeeld label "V_1_1_20" kan hangen. En daarna ontwikkel je gewoon verder.

Als je later die oude versie nog eens terug wilt hebben, dan kun je aan je CVS vragen: geef mij alle files van "V_1_1_20" (bijvoorbeeld).

Je hebt dan die oude versie in één keer met alle files ten tijde van de release bij elkaar. Je hoeft dus niet zelf te gaan zoeken welke revisie van welke file allemaal bij een bepaalde release van je software hoorden.

[ Voor 19% gewijzigd door Verwijderd op 05-01-2005 00:49 ]

[Verwijderd]

Waarschuwing: SPAM!
Darcs is ook versioning system. Ik vind het zelf prettiger dan svn. SVN is trouwens _broken_. Sommige gedocumenteerde features werken al lange tijd niet. De belangrijkste doen het overigens wel. Cvs heb ik gelukkig nooit iets mee gedaan (op downloaden van software na dan). Ik ga voor de tool die het meeste, het makkelijkste doet. Linus gebruikt BitKeeper (die hierboven al is genoemd). Tja, iedereen zijn voorkeur, ookal heb ik geen ervaring met BK.

Het lijkt me een ramp om via jouw methode code te ontwikkelen. Iedereen zou in een branch tegelijkertijd moeten werken, en voor de highly experimental dingen zou je een andere branch kunnen nemen. Ach, het hangt ook af van de mensen natuurlijk. Misschien vinden ze het wel cool om meerdere branches te mergen.

[Verwijderd]

Mmm... darcs ziet er behoorlijk intrigerend uit. Die gaan we eens uitproberen...

[EfBe]

bodiam schreef op dinsdag 04 januari 2005 @ 23:48:
Heilig in geloven is iets anders dan het waarderen of zeggen dat het een goed product is. Ik geloof alleen niet dat het zo slecht is als dat ik denk dat het is.

Het is echt bar en boos slecht. Nu kan men roepen "dat is niet zo", maar dan hebben die personen nooit ellende gezien die CVS kan veroorzaken. Je checkt 50 files in en file 23 gaat fout. oops, wel 22 files ingecheckt en 26 niet, hoe nu verder? Mono heeft veel last gehad van een foute rename waardoor de repository een paar dagen onbruikbaar was.

Je weet niet wat je meemaakt als je CVS aan de kant gooit voor bv Subversion. En dan is Subversion nog een beginnend systeem, waar nog veel features aan kunnen worden toegevoegd die de dure jongens al aan boord hebben. Echt, met Subversion gratis verkrijgbaar met ZEER goede documentatie en voor een groot aantal platforms native binaries zie ik echt niet in waarom iemand op CVS zou blijven doormodderen.

EfBe, wat zijn in jouw context modules? Ik programmeer in Java aan een redelijk groot platform. Check ik een deel niet uit, dan werkt er niets. Ik kan geeneens compileren. Ook al zou het compileren, dan zou het nog niet nuttig zijn omdat ik bepaalde functionaliteit zou missen. Of is dit niet wat je bedoelt met branchen?

CVS werkt net zoals subversion met een edit-checkin systeem. Dit houdt in dat 'uitchecken' niet boeit (bestaat ook niet 'echt'), de server houdt het niet bij. VSS doet dat bv wel en dat werkt dan ook voor geen meter in een groter team. Je checkt dan ook geen files uit, je maakt een local copy van een repository revision, bv de head van de trunk.

Dus je haalt altijd alle source op die je nodig hebt voor je programma. Je wijzigt de files die je moet wijzigen en compileert voor de laatste checkin van die dag of alles compileert en checkt dan de wijzigingen in de trunk.

Waar ik op doelde is dat wat ik ook al eerder aangaf: sourcecontrol is voor het grootste deel organiseren. Gewoon heel simpel je project goed indelen en het werk goed verdelen. Je zegt dat je aan een redelijk groot platform werkt, maar je maakt mij niet wijs dat van de bv 2MB aan sourcecode alles in 1 groot project zit. Bv in .NET deel je je project op in logische delen, die stop je in afzonderlijke projects. Ieder project is een afzonderlijke unit. Het is bv wel een dll en draait niet zonder een host maar het is wel een afzonderlijke unit. Dit houdt in dat die afzonderlijke unit in gecompileerde vorm gebruikt wordt door ontwikkelaars van andere delen van het totale systeem.

Het grote voordeel hiervan is dat je dus zo'n afzonderlijke unit kunt branchen. De rest werkt met de gecompileerde versie verder, en jij werkt aan een nieuwe versie van zo'n unit/module/project. Ben je klaar, maak je een nieuwe versie (branch wordt trunk door merge back of gewoon copy) en men kan gaan werken met de nieuwe versie OF doorblijven werken met de oude versie.

Denk je dat developers aan windows de complete windowsxp source gebruiken om een feature te testen? Denk het toch niet

Hoe zou jij op moduleniveau je code aanpassen dan? En hoe zorg je dat als je wijzigingen in de trunk krijgt van meerdere developers, dat je toch altijd elk moment live kunt gaan?

Laat ik een voorbeeld geven uit de praktijk. De O/R mapper waar ik al 2.5 jaar aan werk, LLBLGen Pro, bestaat uit een aantal subsystemen: GUI (.exe), 3 core assemblies voor verschillende core onderdelen van de designer, per database een driver dll, 5 dlls voor de code generator engine (parsers/interpreter/compilers/andere task handlers), 1 dll voor de runtime core, per db een sql engine (dll), een set shared templates en per db een setje specific templates, daarnaast nog een groep docs.

Ik heb deze gegroepeerd in subversion repositories. Per groep hebben ze een hoofd version nummer, dus de 'designer', de 'code generator', de 'templates', de 'runtime libraries', de 'drivers'. Binnen zo'n groep heb ik trunk/tags/branches folders en binnen de trunk per module een folder. per groep branch ik uit, als ik die ga aanpassen voor een volgende versie bv.

Door deze groepering kan ik ongestraft werken aan de designer zonder de runtime libraries sourcecode ook maar aan te passen of daar ook maar mee bezig te zijn, omdat dat een andere groep is. En nu komt het dus weer aan op organiseren: je moet dus voor je totale systeem, dus als geheel, ervoor zorgen dat je de juiste versies van iedere groep zn elements bijelkaar zoekt voor bv de installer die je klanten krijgen of de CD die je uitgeeft.

Dit werkt erg goed in de praktijk. Tuurlijk kost het even wat tijd om het goed op te zetten en daar moet je even de tijd voor nemen. Maar wanneer je dat op de rit hebt is het echt heel simpel. Ik heb bv allerlei scripts gemaakt (hele simpele .cmd scripts) die source uit subversion halen voor een groep, nant aanroepen (die gewoon de solution build, per groep 1 solution met de verschillende projects) en de assemblies copieren naar een 'distribution folder'. Die folder wordt dan gebruikt voor de installer builder, obfuscator etc. Ik roep 1 batch aan en hij kachelt een installer bij elkaar.

Het enige wat dan nog moet worden gedaan is dat je goed organiseert welke groep wordt geupdate en wanneer dat gedaan wordt, je de verschillende onderdelen upgrade zodat een nieuwe installer ook de nieuwe onderdelen bevat. Dat is veelal niet veel meer dan de branches tot trunk promoveren (in subversion gewoon eerst de trunk taggen als laatste versie van de oude branche (dus moven naar de tags folder) en dan de branched out versie die je hebt geupgrade als trunk copieren), je local copies van de sourcecode omzetten zodat deze dan naar de juiste source wijzen en je bent klaar.

Veel mensen knoeien echter maar wat aan met sourcecontrol, en snappen niet dat het niet alle problemen oplost (logisch, je moet organiseren!). Sourcecontrol systemen implementeren de zaken zoals je die hebt georganiseerd, ze zorgen niet DAT het automatisch georganiseerd verloopt. Sterker: een goed georganiseerd project zou zonder sourcecontrol KUNNEN (maar wel met een daily backup), simpelweg omdat goede organisatie voorkomt dat code merges echt nodig zijn.

[EfBe]

Verwijderd schreef op woensdag 05 januari 2005 @ 00:51:
Darcs is ook versioning system. Ik vind het zelf prettiger dan svn. SVN is trouwens _broken_. Sommige gedocumenteerde features werken al lange tijd niet. De belangrijkste doen het overigens wel.

Welke werken dan niet? Ik ben er nog nooit 1 tegengekomen. Roepen dat iets 'broken' is doe je alleen wanneer het gewoon niet werkt. Darcs, heeft dat een tool zoals Tortoisesvn? Draait het native op windows 2000? Is het snel?

En wat is het nut van een brei patches als ik daarvoor de software heb om dat voor mij te regelen? (overigens kan ik met svn die ook gewoon maken)

[MSalters]

EfBe schreef op woensdag 05 januari 2005 @ 10:02:
[...]
CVS werkt net zoals subversion met een edit-checkin systeem. Dit houdt in dat 'uitchecken' niet boeit (bestaat ook niet 'echt'), de server houdt het niet bij. VSS doet dat bv wel en dat werkt dan ook voor geen meter in een groter team.

Sorry, maar complete onzin. Ik heb in een team van 4000 man gewerkt (vierduizend) waar de developers stuk voor stuk met checkout/checkin werkten. Dat VSS niet fatsoenlijk werkt heeft andere oorzaken (halfwas client/server, net zoals CVS)

Sterker: een goed georganiseerd project zou zonder sourcecontrol KUNNEN (maar wel met een daily backup), simpelweg omdat goede organisatie voorkomt dat code merges echt nodig zijn.

Hahaha. Met dat soort aantallen developers weet je gewoon dat er dingen fout gaan, als je code merges nodig hebt maar niet doet (dwz zonder source control). Je kunt wel zonder code merges, als je exclusive checkout gebruikt.

[ Voor 29% gewijzigd door MSalters op 05-01-2005 10:39 ]

[EfBe]

MSalters schreef op woensdag 05 januari 2005 @ 10:35:
[...]
Sorry, maar complete onzin. Ik heb in een team van 4000 man gewerkt (vierduizend) waar de developers stuk voor stuk met checkout/checkin werkten. Dat VSS niet fatsoenlijk werkt heeft andere oorzaken (halfwas client/server, net zoals CVS)

Checkout - Checkin heeft als nadeel dat wanneer meerdere mensen met een file bezig willen, dat in veel gevallen niet kan (geen multiple checkouts). Wanneer je multiple checkouts gebruikt, doe je eigenlijk het checkout systeem teniet en werk je met edit-checkin (want loggen wie wat uitcheckt boeit dan niet). Bij 4000 man op 1 repository heb je OF multiple checkouts OF de handel dermate fine-grained gegroepeerd dat het er niet toe doet hoeveel mensen er aan werken, daar je veelal met 2-10 mensen op je eigen repositorietje werkt.

[...]
Hahaha. Met dat soort aantallen developers weet je gewoon dat er dingen fout gaan, als je code merges nodig hebt maar niet doet (dwz zonder source control). Je kunt wel zonder code merges, als je exclusive checkout gebruikt.

Erm... ik zei: 'als je goed organiseert'. Dit houdt in dat developers dus dingen doen die anderen niet ook gaan doen, bv file abc.c gaan wijzigen. Jij komt met een voorbeeld aanzetten dat meerdere mensen dezelfde file gaan editen. Dat is niet goed organiseren. Hetzelfde geneuzel komt voor in de database wereld: meerdere mensen willen hetzelfde record gaan wijzigen. Men gaat dan symptoombestrijdende prutsoplossingen verzinnen zoals rowlocking of erger: optimistic concurrency. Ipv het beter op te lossen door ervoor te zorgen dat men niet gelijktijdig die row gaat wijzigen door het werk beter te verdelen. Als user A en B beide row X moeten updaten kan user A beter beide wijzigingen doorvoeren en B iets anders gaan doen. Sourcecontrol is identiek daaraan, met die wijziging dat je bij een goed sourceontrol systeem nog wel kan mergen maar wanneer je je project slecht organiseert je erg veel tijd kwijt bent aan mergeconflicts op te lossen. Indien je dat veel moet doen weet je dat je je project slecht organiseert.

Bij goede organisatie heb je niet het fenomeen dat men in dezelfde file gaat knoeien, maar dat 1 persoon wijzigingen aanbrengt in die file en anderen andere wijzigingen in andere files. En dan kan jij gaan lachen dat dat onmogelijk is, maar zolang zijn sourcecontrol systemen nog niet 'gemeengoed' in de softwarewereld, en al helemaal niet in de database wereld waar men lange tijd veel BL code gewoon in procs in de database bouwde (hoeveel oracle bakken met megabytes aan PL/SQL procs zijn er niet in deze wereld...)

[Verwijderd]

OK, interessant. Maar nu zit ik met het volgende model: Ik heb 1 basis (onderzoeks)code, die we met een stuk of 10 man gebruiken en ontwikkelen. Iedereen heeft er secties inzitten die alleen voor hemzelf interessant zijn, bijvoorbeeld bijzondere statistiek, maar er worden ook regelmatig bugs uitgehaald of verbeteringen aangebracht die in de main branch moeten. Komt dus neer op 10 parallelle progs, die soepel te selecteren patches vanelkaar over moeten kunnen nemen.

Darcs ziet er interessant uit, de decentrale opzet zonder echte branches spreekt me wel aan, maar ik weet niet hoe goed het uiteindelijk is, en het is niet heel algemeen gebruikt. Dat laatste is een voordeel van subversion, lijkt me.
Dus: Welke zou het best zijn?

[Verwijderd]

Je hoeft toch niet te branchen?

Wat is er mis met iedereen gewoon in de trunk te laten werken?

[marcelk]

Misschien heb je hier wat aan:
http://cvsbook.red-bean.com/OSDevWithCVS_3E.pdf

[Verwijderd]

Verwijderd schreef op woensdag 05 januari 2005 @ 16:33:
Je hoeft toch niet te branchen?

Wat is er mis met iedereen gewoon in de trunk te laten werken?

Dat iedereen ook features aan het klussen is die niet in in de trunk thuishoren.Iedereen is effectief de enige gebruiker van zijn eigen ontwikkelde code.

Voordeel van Svn is overigens wel dat het al overal geinstalleerd staat. Maar dat is natuurlijk ook maar een kleine moeite.

@marcelk: Dank, maar die kende ik al. CVS en bK zijn niet echt opties voor mij, helaas.

[ Voor 13% gewijzigd door Verwijderd op 05-01-2005 16:59 ]

[EfBe]

Verwijderd schreef op woensdag 05 januari 2005 @ 16:56:
Dat iedereen ook features aan het klussen is die niet in in de trunk thuishoren.Iedereen is effectief de enige gebruiker van zijn eigen ontwikkelde code.

Dit klopt niet (IMHO). Iedereen heeft ook code van anderen nodig, immers ze werken tezamen aan het complete systeem. Verder snap ik niet dat iedereen features toevoegt die niet in de trunk thuishoren. Je hebt OF een branch voor v2 terwijl v1 in de trunk zit (en het team dat de v2 bouwt zit dus in de branch te werken en niet in de trunk) OF je hebt maar 1 versie en die zit in de trunk.

Iedereen maar wat aan laten rommelen in zn eigen branch kan lekker werken, totdat je code van anderen nodig hebt en het vrolijke mergen begint. Zoals ik al zei: organiseren eerst, sourceontrol later.

[Verwijderd]

EfBe schreef op woensdag 05 januari 2005 @ 18:35:
[...]

Dit klopt niet (IMHO). Iedereen heeft ook code van anderen nodig, immers ze werken tezamen aan het complete systeem. Verder snap ik niet dat iedereen features toevoegt die niet in de trunk thuishoren. Je hebt OF een branch voor v2 terwijl v1 in de trunk zit (en het team dat de v2 bouwt zit dus in de branch te werken en niet in de trunk) OF je hebt maar 1 versie en die zit in de trunk.

Iedereen maar wat aan laten rommelen in zn eigen branch kan lekker werken, totdat je code van anderen nodig hebt en het vrolijke mergen begint. Zoals ik al zei: organiseren eerst, sourceontrol later.

Wel voor ons. Alle ontwikkelaars hebben eigen doelstellingen, willen andere dingen met die code, dus hebben ze bijvoorbeeld andere postprocessing. Nogmaals, we werken niet aan een pakket dat ooit uitgebracht moet worden, maar laat ik zeggen dat iedereen parallel een programma zit te tikken dat vreselijk veel op dat van de rest lijkt. En dus is het zinnig om bugfixes en sommige features te delen, maar zeker niet allemaal.
Wat mij betreft hebben we 1 main waarin alleen de code zit met algemeen gewenste features, die selectief wordt geupdate en volledig als patch werkt voor de rest.
Overigens verwacht ik nou ook weer niet zo veel conflicten dat wat handwerk hier en daar helemaal onmogelijk wordt.
Hoop dat ik nu dingen iets beter heb uitgelegd......

Het komt er waarschijnlijk op neer: Welk pakket kan het beste omgaan met patches van de trunk op een branch zetten.

[alienfruit]

Hoe kan je dan verschillende repositories gebruiken voor in een project, het lijkt me nou niet echt handig om CodeDOM subproject apart op te slaan van het totale project. Als hetn ou gescheiden projecten zijn zoals bij een component, dan okay. Want volgens mij kun je toch geen repositories samenvoegen? Kan je dan niet beter shared folders gebruiken? Op deze manier kun je een project laten sharen in een ander project, bijv. de common class library. Deze library kan je dan lid maken van je project.

Ik ga straks Starteam Best Practices lezen, volgens mij is StarTeam best een degelijk source control systeem, net zoiets als Subversion.

[MSalters]

EfBe schreef op woensdag 05 januari 2005 @ 11:45:
[...]

Checkout - Checkin heeft als nadeel dat wanneer meerdere mensen met een file bezig willen, dat in veel gevallen niet kan (geen multiple checkouts). Wanneer je multiple checkouts gebruikt, doe je eigenlijk het checkout systeem teniet en werk je met edit-checkin (want loggen wie wat uitcheckt boeit dan niet). Bij 4000 man op 1 repository heb je OF multiple checkouts OF de handel dermate fine-grained gegroepeerd dat het er niet toe doet hoeveel mensen er aan werken, daar je veelal met 2-10 mensen op je eigen repositorietje werkt.

nee en nee. 4000 man, exclusive checkouts en (sterk) overlappende groepen. Nou was dat we een omgeving waar software development serieus werd genomen, dus je deed geen checkout zonder een helder, gereviewed plan wat je ging veranderen.
UIteraard heb je met 4000 man wel een heleboel files, en locking was op file nivo.

Erm... ik zei: 'als je goed organiseert'. Dit houdt in dat developers dus dingen doen die anderen niet ook gaan doen, bv file abc.c gaan wijzigen. Jij komt met een voorbeeld aanzetten dat meerdere mensen dezelfde file gaan editen. Dat is niet goed organiseren.

Hoe organiseer je dat beter? Even een mailtje aan 4000 man sturen, of ze aub niet in abc.c willen editen?

Hetzelfde geneuzel komt voor in de database wereld: meerdere mensen willen hetzelfde record gaan wijzigen. Men gaat dan symptoombestrijdende prutsoplossingen verzinnen zoals rowlocking of erger: optimistic concurrency. Ipv het beter op te lossen door ervoor te zorgen dat men niet gelijktijdig die row gaat wijzigen door het werk beter te verdelen. Als user A en B beide row X moeten updaten kan user A beter beide wijzigingen doorvoeren en B iets anders gaan doen.

Humor. Dus als consument A bezig is met het bestellen van de Da Vinci code bij amazon.com (en dus de inventory table moet updaten) dan mag niemand anders dat boek bestellen. Hoe zie je dat voor je?

[Verwijderd]

alienfruit schreef op woensdag 05 januari 2005 @ 20:04:
Hoe kan je dan verschillende repositories gebruiken voor in een project, het lijkt me nou niet echt handig om CodeDOM subproject apart op te slaan van het totale project. Als hetn ou gescheiden projecten zijn zoals bij een component, dan okay. Want volgens mij kun je toch geen repositories samenvoegen? Kan je dan niet beter shared folders gebruiken? Op deze manier kun je een project laten sharen in een ander project, bijv. de common class library. Deze library kan je dan lid maken van je project.

Ik ga straks Starteam Best Practices lezen, volgens mij is StarTeam best een degelijk source control systeem, net zoiets als Subversion.

Nou ja, volgens de claims (en binnen de terminologie) van darcs kan dat dus wel heel behoorlijk. En uiteraard had ik nu het hele zooitje ook wel met wat shared libraries opgezet, maar we praten hier over een Fortran code die al 15 jaar gebruikt wordt, de resten F77 zitten er nog in. En nee, herschrijven is geen optie, bovendien is fortran wel gewoon de ideale taal in dit geval.

[EfBe]

MSalters schreef op woensdag 05 januari 2005 @ 20:14:
[...]
nee en nee. 4000 man, exclusive checkouts en (sterk) overlappende groepen. Nou was dat we een omgeving waar software development serieus werd genomen, dus je deed geen checkout zonder een helder, gereviewed plan wat je ging veranderen.
UIteraard heb je met 4000 man wel een heleboel files, en locking was op file nivo.

Met 4000 man in dezelfde vijver vissen lijkt me erg efficient werken! Maar waarom had je een gereviewed plan nodig? Toch voor de organisatie van het project?

[...]
Hoe organiseer je dat beter? Even een mailtje aan 4000 man sturen, of ze aub niet in abc.c willen editen?

Nee natuurlijk niet, je deelt je project op in subprojects zodat een build ook niet op 4000 checkings hoeft te wachten.

[...]
Humor. Dus als consument A bezig is met het bestellen van de Da Vinci code bij amazon.com (en dus de inventory table moet updaten) dan mag niemand anders dat boek bestellen. Hoe zie je dat voor je?

Je weet best wat ik bedoel. Ipv in-order changes van table rows doe je dat per order, dus de orders komen sequentieel binnen. Beter voorbeeld was bv geweest dat user A en B beide klantenrecord X gaan wijzigen bij de afdeling inkoop.

[-FoX-]

Ik heb momenteel ook een lokale CVS server draaien en heb er tot hier toe nog niet echt problemen mee gehad. Het zijn dan ook maar hobbyprojectjes die erop gestored worden. En er wordt max. met 3 users tegelijkertijd erop gewerkt.. alledrie netjes in dezelfde trunk

Maar dit is waarschijnlijk toch niet de juiste manier van werken.. Welke manier is dit dan wel, voor de kleinere projecten? Want ik kan me inbeelden dat het nodeloze branchen/mergen van je source ook niet echt nuttig is.

Wanneer kan je het beste branchen, wanneer het beste terug mergen?
Bvb een standaard webapplicatie, met crud-operaties op de users, login, lijsten opvragen, zoekfunctie, upload, .. Ga je dan al deze losse modules branchen en loskoppelen van elkaar?

Is het dan ook niet zo dat je dit feitelijk beter overlaat aan een CVSadmin? Als developer zou het toch voldoende moeten zijn om checkin/out, history, annotate van code te doen.

Ik ben niet zo een CVS kenner, ik gebruik het feitelijk ook alleen om mijn src te 'backuppen' en zodat er geen versies verloren gaan..