Død over CVS!

Vi har længe været utilfredse med CVS som versionsstyringsværktøj, ("VCS") i FreeBSD og listen over fejl og mangler er alen lang.

Men at skifte VCS er ikke noget man bare gør, slet ikke når man har et så stort repository (1.8 Gbyte, 70k filer med 800k revisioner.) og mange (223) brugere.

Dertil kommer vores "ports" repository på 1.25GByte, 176k filer og 942k revisioner, og et par andre mindre repositories, men de bliver i CVS indtil videre.

Den første hurdle var at vælge hvad vi skulle skifte til og det tog et par år inden der var en klar kandidat.

Vi har f.eks det ufravigelige krav at en given check-in skal kunne fjernes helt fra vores repository.

I forhold til den normale måde at tænke versionsstyring på lyder det fuldstændigt bagvendt, men det er det ikke.

FreeBSD projektet var et af det første Open Source Projekter der åbnede vores VCS repository så alle kunne hente en kopi.

Prisen for den beslutning er naturligvis at vi ikke kan bruge VCS systemet til at begrave vores fejltagelser.

F.eks kom der på et tidspunkt et surt brev fra en advokat om at "Tetris" faktisk var et varemærke og jada jada jada og at vi skulle fjerne alle spor af "xtetris" fra vores repo.

I CVS er det nemt nok, man griber en tekst-editor og retter repo filerne. Langt fra en optimal metodik, men den virker.

I Mecurial ("Hg") kan det slet ikke lade sig gøre, for alle checkins signeres med en kryptografisk signatur baseret på deres grundlag, og man kan ikke efterfølgende save et trin ud af trappen.

Andre VCS systemer kunne simpelthen ikke klare mosten, typisk krævede de urimeligt store maskiner for at håndtere vores repo.

Eller der manglede de nødvendige faciliteter til at kunne integreres i vores projektinfrastruktur.

F.eks er vi nødt til stadig at fylde alle vores ændringer i vores gamle
CVS system, således at brugere i en overgangsperiode (på flere år) fortsat kan hente FreeBSD med "cvsup" og importere derfra, ind i deres egne VCS systemer. Den dag idag er der VCS systemer der ikke har eventdrevne export faciliteter.

Efterhånden som vi kom ned af listen, faldt det ene VCS efter det andet fra.

Til sidst var der kun en realistisk kandidat: Subversion.

Subversion ligner fra brugersiden CVS ganske meget og det er natuligvis en stor fordel på kort sigt.

Men hvad der er mere vigtigt er at Subversion projektet har nogle fornuftige og pragmatiske folk, der har taget imod vores forslag og patches uden de store politiske sværdslag.

(De har også humor. Det er min email, men de har lavet websiden. Husk at trykke reload.)

Men så kommer vi til det næste problem:

Konvertering af vores CVS repository til Subversion og tilretning af alle vores underlige værktøjer.

Opgavens karakter understreges af at vores repo er standard testcase#1 af konverteringsværktøjer i VCS branchen.

Derfor vil forbavsende velorienterede sælgere af VCS software ofte pege på "FreeBSD's repo som et eksempel på hvornår man end ikke skal forsøge en konvertering".

Av.

Men vi har folk i FreeBSD der ikke stikker op for bollemælk.

Peter Wemm f.eks.

Efter at have arbejdet på sagen, 12-15 timer hver dag i en måned, siger Peter at hans python script fra helvede ("I can write PERL4 in any language!") virker som det skal.

Konverteringen ruller over de næste 8 timer.

... og i løbet af et par dage eller uger er vi på plads og i orden igen.

phk

Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mikkel Høgh

Ja, som en anden CVS-bruger kan det glæde mig at se at der i det mindste er nogen der slipper væk.

Jeg er desværre stadig bundet til CVS – Drupal, som er mit primære arbejdsværktøj, hænger desværre fast i CVS – og som for at føje spot til skade er det også det system vi bruger på min arbejdsplads i øvrigt.

Og listen over fejl og mangler er som du selv siger, lang. Hvor koster det dog meget ærgelse og besvær at bruge frem for et af de mere moderne systemer – selv foretrækker jeg Git…

bruger min arbejdsplads det intern

  • 0
  • 0
#2 Mads N. Vestergaard

Også herfra skal der da lyde et tillykke.

På mit arbejde har vi i et godt stykke tid benyttet Subversion, og er super glade for det.

Har endelig også fået overbevist den sidste mand, som aldrig rettede i nogle filer, om at han skulle benytte Subversion, til at rette i de filer han aldrig rettede. Problematikken opstod jo i at han en sjælden gang gjorde, det, men når det ikke skete så tit, gjorde det ikke noget at han rettede dem direkte, han kunne dog ikke forstå hvorfor vi andre altid fjernede han ændringer ;)

Har tidligere benyttet CVS på andre projekter, og har heller ikke været super lykkelig over dette, men "in lack of better", er det da blevet brugt.

  • 0
  • 0
#3 Død Profil

Jeg så for et stykke tid siden denne: http://weblogs.java.net/blog/kohsuke/archive/2008/04/hudsons_scm_is.html

Det er selvf. et meget lille projekt ifht. FreeBSD's kodebase.

Lige lidt nysgerrig; bruger I Berkeley db eller andet til storage i jeres repo? Har I talt med nogen af dem som står for f.eks. Apache's ASF repo? (godtnok "kun" 661k+ revisions: http://svn.apache.org/repos/asf/ )

Ellers velkommen til Subversion, merging mellem branches i historiske versioner husker jeg var min grund til at skifte :)

Mvh, Søren

  • 0
  • 0
#4 Deleted User

Har i på noget tidspunkt overvejet at involvere jer i udviklingen af OpenCVS, eller var det for umodent? Eller er det for meget "at opfinde den dybe tallerken forfra"?

Umiddelbart var det jo rent faktisk en mulighed for at holde kompatabiliteten med CVS, og så stadig få de manglende features (som kunne være spændende at høre mere om).

http://www.opencvs.org

  • 0
  • 0
#5 Poul-Henning Kamp Blogger

OpenCVS klarede slet ikke vores repo så vidt jeg husker.

I tidens løb er der sket forskellige former for fusk, ikke mindst i forbindelse med imports på vendor-branches og lign. og det kunne OpenCVS ikke rigtig kapere.

Den anden side af sagen er at OpenCVS ikke ville give os nogen håndgribelige fordele og dermed årsager til at skifte.

En væsentlig del af encitamentet er at slippe af med vores Perforce udviklings repo, som aldrig rigtig er kommet til at spille sammen med CVS og som ikke helt er gearet til vores "lav en kopi af hele systemet" hvergang nogen får en sjov ide.

Jeg har ikke styr på den præcise konfiguration af vores svn repo, så jeg ved ikke hvilket format det har.

Poul-Henning

  • 0
  • 0
#7 Poul-Henning Kamp Blogger

"Men kan svn rent faktisk fjerne et commit helt? 1.4.x kan vist ikke, ud over at lave et mega grimt eksporterings- og import-hack."

Det er godt nok til os, bare der er en mulighed, den behøver ikke at være nem eller elegant, det er kun noget vi bruger som sidste udvej.

Poul-Henning

  • 0
  • 0
#8 Thomas Ammitzbøll-Bach

Jeg har dog et par ting, som jeg ikke kan lide...

1) Branches og $Id$: Når alle commits bare får et fortløbende nummer, kan jeg ikke umiddelbart af $Id$ se, hvilken branch, jeg har bygget. Jeg savner et keyword, som jeg kan få ekspanderet til branch-identifikation.

2) Tags: Et tag og en branch er det samme. Det er selvfølgelig en temperamentssag, men jeg kan ikke lide, at nogen uforvarent kan komme til at commit'e til et tag.

3) Merge conflicts: Nu er jeg nok bare en gammel prut, men jeg kunne altså bedre lidt CVS-måden med >>> og <<<. Igen en smagssag.

Når det er sagt, så er SVN en værdig afløser for CVS! CVS har tjent os vel, og når tiden efterhånden er kommet til at skifte til noget nyt, så er det nok en god ide at tænke over, hvad der trods alt er godt ved CVS. Det synes jeg, at SVN-drengene har gjort. SVN er i min bog en bedre CVS end CVS.

Thomas

  • 0
  • 0
#9 Peter Toft

Jeg har brugt CVS i 10+ år og kender CVS i stort set alle hjørner. Det er en gammel sag og det kører ikke så godt mht. at få lavet releases og få styret antallet af fejl nedad. Jeg har selv været i gang på bugs-cvs listen en del gange. I mit forrige arbejde valgte jeg bevidst SVN for at prøve det - det var et godt valg, og det er genialt at det kan integreres i f.eks. Trac - http://trac.edgewall.org/. Jeg har været admin på mange CVS projekter på størrelse med FreeBSD i tyngde og til kæmpe projekter var min erfaring for et år siden at SVN stinker - det er for langsomt. Måske det er blevet bedre siden - dunno.

  • 0
  • 0
#11 Poul-Henning Kamp Blogger

Der er en ældre selv-deklaration for fire af VCS værktøjerne i en FreeBSD sammenhæng her:

http://wiki.freebsd.org/VersionControl

Den blev lavet tidligt i forløbet, for at have et sted at holde et "scoreboard".

Det er en selv-deklaration, og det er langt fra alle de grønne felter der er enighed om, men det er også ret tydeligt at f.eks Hg er langt fra målet.

Punkterne har naturligvis ikke lige vægt og der er andre faktorer der har spillet ind også, ikke mindst kontakten på det personlige niveau til projektet bag VCS værktøjet.

Alt det er blot for at sige at jeg kan ikke huske hvad det var GIT specifikt faldt på, men det har ikke været i spil i lang tid.

Poul-Henning

  • 0
  • 0
#12 Carsten Sonne

Jeg kan kun på det kraftigste anbefale Microsoft Team Foundation Server. Selvfølgelig er det kun relevant for udviklere som bruger Visual Studio.

Det har alle funktioner man kan ønske sig. Merging, branching, rollback osv. og det fungerer bare.

Efter at have arbejdet med et par andre source control systems hvor jeg har haft en del problemer, kan jeg kun sige at jeg har stor set ingen problemer mere. For en gang skyld har Microsoft lavet noget der bare fungerer 100% (næsten).

Mvh Carsten Sonne Larsen

  • 1
  • 0
#13 Michael Rasmussen

phk,

Hvis jeg forsøger mig med dit link, får jeg følgende respons:

Warning: You triggered the wiki's surge protection by doing too many requests in a short time. Please make a short break reading the stuff you already got. When you restart doing requests AFTER that, slow down or you might get locked out for a longer time!

  • 0
  • 0
#14 Poul-Henning Kamp Blogger

"Jeg kan kun på det kraftigste anbefale Microsoft Team Foundation Server. Selvfølgelig er det kun relevant for udviklere som bruger Visual Studio."

Det har altid moret mig at Microsoft selv bruger Perforce.

Poul-Henning

  • 0
  • 0
#15 David Jack Wange Olrik

Der er en ældre selv-deklaration for fire af VCS værktøjerne i en FreeBSD sammenhæng her:

http://wiki.freebsd.org/VersionControl

Sjovt at se at git er det SCM med flest grønne bokse.

Alt det er blot for at sige at jeg kan ikke huske hvad det var GIT specifikt faldt på, men det har ikke været i spil i lang tid.

Det har sikkert været bruger-interfacet til git, der tidligere krævede minimum en Ph.D eller to for at bruge, der gjorde at i valgte det fra.

Git er kommet extremt langt inden for det sidste års tid, og er blevet utroligt rart at bruge.

Subversions "branches" er ikke rigtige branches, og man skal selv stå for merge housekeeping - og altså holde tungen lige i munden når man merger. I git er branching og merging legende let, og en fornøjelse at bruge.

Jeg synes at det ville være synd om i ikke lige kiggede en extra gang på git, for det er så meget bedre end subversion.

/David

  • 1
  • 0
#19 Troels Liebe Bentsen

Mecurial eller Git havde nok været et noget mere moderne bud og det burde også kunne lade sig gøre at genskrive historien med et export/import hack og et lille script til at rette folks repos op med den nye "forbedrede" historie.

Men subversion er da et gevaldigt skridt op fra CVS selv om den er lidt langsommere på nogen punkter. Man slipper da i det mindste for inkonsistente checkouts og revisions kan bruges til andet end at holde styr på hvor mange gang man har ændret en fil.

Men jeg vil da anbefale git som en god subversion klient, så kan man får de flest fordele fra git. Om ikke andet er det sundt at snuse til en anden måde at gøre tingene på en gang i mellem, selv for en gammel kernel hacker :).

git svn clone http://domain.tld/svn/repo # For hele historien, kommer nok til at tag lidt tid for jeres repo :), men man kan så også dele sin git version af repo'et bagefter.

eller

git svn init http://domain.tld/svn/repo git fetch -r # Henter historien fra sidste revision

Man kan læse mere her: http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-fetch

og her:

http://git.or.cz/course/svn.html

Typisk git/svn workflow:

git svn rebase # samme som svn update while(coding) { vim hello.c # lave ændring git commit -m 'mine fine ændring' } git svn dcommit # samme som svn commit

  • 0
  • 0
#20 Peter Toft

Ok - så tager vi handskerne af :)

Jeg prøvede sammen med en kammerat i dag at importere et kæmpe projekt fra CVS til SVN. På localhost var SVN kun ca. 2x langsommere end CVS - mens SVN var 5x sløvere (give and take) med remote SSH access.

ØV! Jeg ville ellers gerne nuke CVS...

  • 0
  • 0
#22 Troels Liebe Bentsen

Det er sku en aftale, vi kan da godt battle lidt :)

Ja det er helt rigtigt at SVN er langsommer til nogen ting, men den gør også en del mere for at undgå korruption af ens checkins og checkouts.

Du behøver aldrig lige lave en ekstra svn update bare for at være sikker på du fik alle filerne med, hvis du nu var uheldig med at ramme midt i en commit.

Ligeledes er branches og tags meget billige i SVN, hvor det både koster tid og plads i CVS.

Og så kan vi snakke om renames og det at kunne slette filer og bibliotek uden at miste historik.

Ydremere gør CVS det ekstremt besværligt at rydde op og refakturere sit projekt. Og når det er besværligt at gøre det rigtige så giver det dårlige vaner og dårlige kode. Hvilet burde være nok til at diskvalificere det

Om det er 5x eller 10x gange langsommer til et checkout eller hvad der blev målt på er nok ikke så vigtigt når det kommer til stykket. Mere at det lever et minimum af features, så man kan bruge det.

Men Peter hvis du stadig er fanget på CVS, så spring subversion over og brug git, hg, bz. De er både hurtigere end CVS og Subversion og har flere features, lige ledes kan du lave din arbejdes model som du ønsker den, uden at skulle ligger under mærkelige begrænsninger i gammel slam kode.

Der er import værktøjer til alle sammen, så det er bare at gå i gang. Og der er endda en CVS server til git, du kan bruger hvis du har gamle klienter som du ikke har lyst til at skifte ud.

Jeg lejer også gerne mine erfaring ud for et venligt ord, rødvin, øl eller kolde kontanter, alt efter formål og omfang.

For lidt farvet information om git: http://video.google.com/videoplay?docid=-2199332044603874737&q=git+Linus...

  • 0
  • 0
#23 Ulrik Gammelby

Kan I uddybe den holdning til ClearCase en smule? Så længe man holder sig fra windows-klienterne har jeg personligt mest gode erfaringer med det (især sammenlignet med CVS og TFS). Og jeg antager det ikke er disse windows-klienter, der har fået FreeBSD-folk til at sidde og grine/græde...

  • 0
  • 0
#24 Mikkel Kirkgaard Nielsen

Har også selv forestået et firma-wide skift af VCS til SVN. Vi anvendte tidligere MKS Source Integrity (RCS-klon med noget brugerflade ovenpå), som folk var hamrende nervøse for, hver gang de skulle lave noget andet end alm. commits. Det blev betragtet som sort magi, som kun få kunne udføre, for der var så mange ting der kunne gå galt. I længden havde det medført meget dårlige praktikker omkring opbygningen af kode træer og procedurer omkring (ikke-eksisterende) tagging etc.

Udrulningen af SVN har været som at komme ud i lyset fra et mørkt rum, fuld styr på de atomiske commits, nemt overblik over kodetræet (her er TortoiseSVNs repository browser uundværlig, er der evt. nogle der har fundet/arbejder på noget lignende til ikke-windows platforme?), meget nem og gennemskuelig branch/tag procedure som anvender den samme grundlæggende mekanisme (copy with history), cross-platform klienter i mange forskellige afskygninger, fantastisk anvedelig auto-merge/konflikt håndtering, god og tilgængelig dokumentation, client-server løsning med flere server muligheder og ting jeg sikkert har glemt men nyder hver dag :)

Overordnet meget positiv oplevelse herfra, selvom vi har haft et par issues med Windows klienten TortoiseSVN, men ikke noget der har været show-stoppere. Alle er glade, selv de mere applikations-fokuserede udviklere som ikke gider at være værktøjs-specialister.

Men Thomas, lige et par kommentarer til dine ankepunkter:

  1. [branch/tag id] Er det ikke bare $URL$ du mangler kendskab til? Den ekspander til filens fulde sti, inklusiv evt. branch/tag, så er det jo bare at mingelere lidt med nogle streng funktioner hvis du kan skal bruge branch/taggets navn. Se evt. http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.props.spec...

  2. [commit til tags] Det har også være en bekymring for mig, og jeg har endda et par gange stået og kigget folk over skulderen og stoppet dem i at comitte til et tag :) Men... det kan jo løses med den geniale repository hook funktionalitet! Lav et commit-hook (shell, perl, whatever script.sprog du mestrer) på serveren der tjekker om stien indeholder "tag" (eller "rødgrødmedfløde" hvis det er den vedtagne politik), og så kan du afvise committet right-there med en non-zero returværdi, og en stderr melding der bliver relayet til klienten ("commit i branch, ikke tag!" eller "rød grød med fløde er ok, men ikke i vores kilde kode, tak."), uden at du lukker et komma ind på serveren... Se evt. http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.ref.reposhooks

  3. [konflikt indikering] Prut og prut ved jeg nu ikke, men emnet er da lidt subjektivt :) Jeg har ikke meget erfaring med CVS, men ifølge det her http://www.eyrie.org/~eagle/notes/cvs/conflicts.html synes jeg det ser ud til at CVS gør det på samme måde, hvor oplever du forskellen? Konflikt indikeringerne er forøvrigt helt hardcoded, ingen mulighed for konfiguration (hvilket også ville give bøvl ved evt. scripting), se http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_wc/merge.c?revi...

Mikkel,

  • 0
  • 0
#25 Kasper Tonsberg

Ang. ClearCase: Jeg har kun arbejdet med Unix-kommandolinie versionen, så jeg skal ikke kunne udtale mig om evt. issues i Windows-klienterne. Men generelt er alting meget mere besværligt i ClearCase end i f.eks. SVN, og konceptet med at koden kan ændre sig under fødderne på en, er ikke særligt hensigtsmæssigt i mine øjne. Med ClearCase kan man aldrig være sikker på hvilken tilstand ens kodebase er i, eller hvilke versioner af diverse filer man kan se på et givet tidspunkt. Det er f.eks. umuligt at lave en rekursiv atomisk check-in - således at hvis nogen sidder og kompilerer din kode mens du checker ind, vil de se forskellige versioner af dine filer, alt efter hvor langt du er nået i check-in proceduren. Du kan bl.a. også checke en fil ud som "reserveret", dvs. at ingen andre end dig kan ændre i filen. Det er uhyrligt morsomt, når nogen har gjort det og så taget på ferie i 3 uger. I ClearCase skal der blot et lille fejltrin til, så er dine filer slettet eller gjort usynlige. Hvis en fil ved en fejl er oprettet uden skriverettigheder til dig, og bagefter checket ind, kan du godt læse filen, men når du så checker den ud, forsvinder den sporløst. Hvis du opretter nye filer i et dir, men der i mellemtiden er en anden der har checket en ny version af dir'et ind, kan du ikke checke dine filer ind, uden at un-checkoute dir'et først (hvorved dine filer forsvinder), og checke det ud igen.

Jeg kunne blive ved..... systemet er designet helt forkert fra bunden, sikkert af en person der ingen kendskab har haft til andre VCS systemers måde at gøre tingene på. Men de har sikkert nogle enormt smarte sælgere ansat...

  • 0
  • 0
#26 Carsten Sonne

"Det har altid moret mig at Microsoft selv bruger Perforce."

Mit bedste bud vil være, at det skyldes ting som strategi, historie og økonomi. Men det har en ret dårlig signalværdi for Microsoft. Det i sig selv, kan man godt more sig lidt over.

Mvh Carsten Sonne Larsen

  • 0
  • 0
Log ind eller Opret konto for at kommentere