CVS versus ClearCase

Dit document is gebaseerd op mijn persoonlijke ervaringen met CVS en ClearCase.

Samenvatting

CVS heeft eigenlijk alleenmaar voordelen tov. ClearCase. ClearCase kan goed werken mits je de beheerders en gebruikers op cursus stuurt, je bereid bent een beheerder permanent bent te betalen voor circa 0,1 FTE (Full Time Equivalent) en je bereid bent te leven met een aantal onhandigheden (work arounds). CVS werkt eigenlijk altijd omdat het eenvoudig, robuust en de de facto standaard is. Daarom is de inzet van CVS naar verwachting altijd goedkoper dan die van Clearcase.

CVS:

• Robuust.
• De facto standaard.
• Eenvoudig in beheer:
  • Nauwelijks tot geen training nodig voor gebruikers en beheerder.
  • Beheerinspanning: nihil.
  • Concurrent versions concept eenvoudiger en minder bewerkelijk dan streams concept.
• Open Source.
• Superieure functionaliteit (met name: concurrent versions, CVS keywords).
• Eclipse plugin werkt zeer goed.
• Behalve de Eclipse plugin zijn er nog vele andere client GUIs beschikbaar (oa. WinCVS, TortoiseCVS).

ClearCase:

• Minder robuust (met name: checkin/checkout faalt soms waardoor de lokale workspace corrupt kan raken, er komen soms files in lost+found terecht en die krijg je er heel moeilijk wer weg).
• Geen standaard.
• Complex in beheer en gebruik:
  • Zeker training nodig voor beheerder en eigenlijk ook voor gebruiker.
  • Beheerinspanning al gauw 0,1 FTE.
  • Streams concept ingewikkelder en bewerkelijker dan concurrent versions concept.
• Commercieel product.
• Minder functionaliteit (met name: geen concurrent versions, geen keywords).
• Eclipse plugin werkt niet goed.
• Alleen de GUI van Rational is naast de Eclipse plugin beschikbaar.

Veel voorkomende misverstanden

Hieronder een aantal veel voorkomende misverstanden over ClearCase en andere Rational tools en waarom ze niet kloppen:

• Veel mensen denken dat RUP betekent dat je Rational tools moet gebruiken. Dat is onzin. RUP is een proces beschrijving (een verzameling best practices) die onafhankelijk is van de gekozen tools. Dus: RUP ≠ Rational tools.
• Veel mensen denken dat UCM betekent dat je Rational tools moet gebruiken. Dat is niet waar. Dus: UCM ≠ Rational tools.
  UCM is een proces dat change management koppelt aan configuration management. Uitgangspunt zijn activities/findings, waaraan wordt gewerkt en die worden opgeleverd. Deze opdeling van het proces is een best practice die onafhankelijk van de gekozen tools is. Waar het bij UCM vooral om gaat is de traceability van die activities/findings, wat zogenaamd zogenaamd beter kan met ClearCase dan met CVS. Dat is niet waar. Bij ClearCase kun je checkouts/checkins koppelen aan activities/findings in ClearQuest, maar dat werkt niet erg gebruikersvriendelijk en er kan gemakkelijk een verkeerde activity of finding gekoppeld worden aan een checkin/checkout. Bij CVS kun je bij checkins (= commits) een checkin commentaar toevoegen. Je kan in dat commentaar refereren naar een activity/finding nummer. Dat is gebruikersvriendelijker, flexibeler en zeker niet meer fout gevoelig. Middels het CSV keyword $Log$ kun je vervolgens deze commit (= incheck) commentaren opnemen in de file. Dus: Activities/Findings traceability ≠ Rational tools.
  
  NB. Een alternatieve tool-onafhankelijke methode is om het javadoc keyword @since te gebruiken. In dat geval stel je verplicht dat men een @since regel opneemt in de class header per keer dat men een file commit. Voorbeeld van zulke @since regels:

  @since 2006-02-01 Jan Klaassen: Initial coding (activity A1234).
  @since 2006-02-08 Ronald Koster: Fixed finding F3210.
  

• Traceability van requirements kun je het beste regelen via één van de volgende tool-onafhankelijke methodes:
      Via JUnit TestCases (voorkeursmethode, sluit nauw aan bij Test Driven Development):
  • Maak voor elke Use Case een JUnit TestCase, en voor elke flow van de Use Case een test-methode.
  • Voorbeeld: Use Case "Doe een girale betaling", met flows: basic flow (betaling lukt), betaling mislukt vanwege te laag saldo, betaling mislukt vanwege onjuiste gegevens tegenreking. Dan krijg je dus de TestCase TestUCDoeGiraleBetaling met de methodes testBasicFlow, testAlternativeFlowOnvoldoendeSaldo, testAlternativeFlowOnjuisteTegenrekening.
      Via speciale javadoc tags:
  • Label alle requirements (bijvoorbeeld: SRS-UC-DOE-GIRALE-BETALING).
  • Vermeld in de javadoc (of in het javadoc equivalent indien een andere taal dan Java gebruikt wordt) van de code die de requirement realiseert (ook wel implementeert) via een speciaal javadoc keyword: @srs id="SRS-UC-DOE-GIRALE-BETALING" info="Alleen de basic flow." (het info attribuut is optioneel).
  • Met een tool, bijvoorbeeld XDoclet, kun je vervolgens eenvoudig traceability rapporten maken.
  Dus: Requirements traceability ≠ Rational tools.

Subversion (SVN)

Aangezien Subversion de beoogd opvolger is van CVS geldt dit verhaal ook voor Subversion.

Links