Jeg har før blogget lidt om distribueret versionsstyring (DVCS), og her kommer lidt mere.
En af de store fordele ved at have en decentraliseret opfattelse af versionshistorikken er, at man ikke har alle sine æg i en kurv. Et centralt repository kan være mere eller mindre utilgængeligt, og har man prøvet det, så ved man hvor fortabt man føler sig. Det kan være så alvorligt, at man skal til at have fat i backuppen, selvom det heldigvis er yderst sjældent. Men det kan såmænd også være noget så simpelt, som at man er udenfor rækkevidde (ja, det kommer nok som et chok, men det er faktisk stadigt muligt at finde steder, hvor der ikke er nogen form for netadgang!).
Skulle man så være helt uden mulighed for at kigge i historikken - eller for at kunne checkpointe udviklingen undervejs med velplacerede commits? Nej vel. Og her kommer distribueret versionsstyring virkelig til sin ret. Og der er jo ikke noget som forhindrer en decentraliseret struktur i netop at have struktur, og derfor i at have et repository, som er mere lige end alle de andre.
Men hvad nu, hvis der allerede er truffet en klog og velovervejet beslutning om at bruge f.eks. Subversion? Er man så tvunget til hele tiden at være online for at få det fulde udbytte?
Ja, i princippet, og så alligevel ikke. For der er jo som udgangspunkt ikke noget som forhindrer en i at versionsstyre de samme filer i to forskellige versionsstyringssystemer, som f.eks. Subversion og Git. Så ville man kunne have en offline historik, offline commits og alligevel kunne koeksistere fredeligt med de andre brugere af det centrale repository.
Dvs. ikke ud over, at det bliver et koordineringsmæssigt mareridt. F.eks. skal ændringer fra det ene skal committes manuelt i det andet.
Men heldigvis er der andre, som har fået samme tanke. Det er f.eks. lavet en integration imellem Git og Subversion med titlen git-svn. Er man mere til Mercurial, så bør man nok holde øje med hgsvn, selvom der vist stadig er plads til forbedring der.
Hvis man kaster sig ud i hybrid versionsstyring af denne slags, så husk at det ikke skal være for at kunne styre at lave sjældne monster-commits - der skal stadig committes de samme sammenhængende klumper af funktionalitet så ofte som praktisk muligt. Når det er interessant, så er det for at dels at kunne arbejde offline, og dels for at kunne lave lokale commits - commits, som ikke behøver være så afrundede eller komplette som ellers - ja, faktisk behøver de slet ikke kunne compilere, og som derfor kan ske undervejs - og ikke først når man er helt sikker på at være færdig.
3 kommentarer:
Det er en virkelig interessant tanke, må jeg sige.
Det er en radikal ændring i forhold til commits, som man er sikker på kan compilere (og eventuelt klare en tur gennem en gang continuous integration test). Nogle gange kan man godt sidde med et wicked problem, og der vil sådan et commit til en lokal versionsstyring da helt sikkert være guld værd. Netop fordi man bare kan committe hver gang, man føler, at man er på rette vej og er kommet lidt tættere på en løsning.
Nu kan jeg så bare sidde og ærgre mig gul og grøn over, at jeg til daglig ikke bruger Subversion!
Fremfor at hoppe ud i at forsøge at arbejde med andre versioncontrolsystemer synkront med et Subversion repository, var et mindre radikalt skridt at prøve sig med SVK, som netop er et for på at udvide Subversion til et decentral repository SCM system. I samme hug forsøger SVK at forbedre på SVN performance, merge mm. Check det ud, hvis I har mod på lidt 'fagre nye' Subversion verden.
Mikis, SVK er præcis, hvad jeg sigter til. Snedigt, at den ikke kun kan spejle Subversion repositories, men også f.eks. CVS repositories. At det internt baserer sig på Subversion er vel mest en implementationsdetajle, og det gør det vist hverken mere eller mindre Subversionvenligt end de alternativer, som jeg nævner.
Men bestemt værd at holde øje med - jeg kendte den ikke, så tak for tippet!
Send en kommentar