Samkjøring av versjoner

Samkjøring av versjoner er, sammen med posting av versjoner, en naturlig del av det å jobbe med versjoner. Posting tilgjengeliggjør endringer utført av enkeltpersoner for andre, mens samkjøring drar disse «publiserte» endringene inn i «din» versjon. Hva skjer egentlig når vi samkjører?

Versjonstreet

Etter at en Enterprise geodatabase er versjonert, vil alle endringer som gjøres i de versjonerte featureklassene og tabellene, legges i deltatabellene. Sammen med hver endring, legges det et State Nummer, og det er disse statene som sier noe om hvor endringen hører hjemme.

Alle stater knyttes sammen i det vi kaller versjonstreet. Dette treet beskriver hvilke endringer, eller stater, som henger sammen og danner endringene i en versjon. Dette gjelder også defaultversjonen. Den har også sine endringer i en serie stater.

Når vi lager en ny versjon, vil den peke på en gitt state i databasen, og alle endringer vi utfører vil bygge på denne staten. En versjon er egentlig bare en «merkelapp» for en state i databasen.

Samkjøring henger tett sammen med versjonstreet. Hvordan kan vi tenke oss at versjonstreet ser ut med «vår» versjon? Den beste måten å se det på er å se på det som et tre, med rot, stamme, grener og blader:

Figur 1. Viser hvilke deler versjonstreet består av og hvor de enkelte delene befinner seg i databasen.

Rota er de radene som ligger i businesstabellen. Stammen er endringene i alle versjoner, inklusive defaultversjonen. Det er verd å merke seg at dette er en litt forenklet modell – den kan være mer kompleks, men viser hvordan ting henger sammen i versjonstreet.

Hva skjer når vi samkjører?

Når vi tenker samkjøring fra ArgGIS Desktop, tenker vi det som om vi «drar» endringer fra den versjonen vi samkjører mot, normalt er det defaultversjonen (DEFAULT), og inn i vår versjon. Siden vi normalt samkjører mot DEFAULT-versjonen, vil vi bruke DEFAULT som referanse videre i beskrivelsen. Samkjører vi mot andre versjoner, må referansen til DEFAULT erstattes med den versjonen vi samkjører mot.

I samkjøringsprosessen vil ArcGIS sjekke om samme objekt er endret både i vår versjon og DEFAULT. ArcGIS finner ut av dette ved at den sammenligner OBJECTID’er i vår versjon mot OBJECTID’er i DEFAULT som er endret siden versjonen ble opprettet, eller som er endret siden siste samkjøring.

Finner ArcGIS to like OBJECTID’er, betyr det at dette objektet er endret i begge versjoner og vi har en potensiell konflikt. Litt avhengig av hvordan vi har sagt at konflikter skal oppdages, skjer det en av to ting: 

 1. Vi finner konflikter basert på rad: Dette betyr at dersom samme rad er endret i de to versjonene, vil vi få en konflikt. Dette er standard.

 2. Vi finner konflikter basert på kolonne: Her sjekkes det litt videre. 

Her må samme attributt på de samme objektene være endret i begge versjoner. Denne vil normalt vise færre konflikter enn alternativet over.

Når vi har fått konflikter, må disse løses. Hva skjer i databasen når vi samkjører? Når vi samkjører, vil versjonen vår, kort forklart, flyttes lengre opp på stammen. Det som i praksis skjer, er at vi flytter festepunktet for versjonen på stammen høyere opp på stammen. Versjonen vår peker mot en høyere state i versjonstreet.

Figur 2. Samkjøring av en versjon flytter versjonen (grenen) oppover på stammen.

En state i databasen er en endring. Alle endringer som gjøres i databasen får sin egen, unike, state. Alle stater vil komme kronologisk i databasen. Vi kan, på en måte, se hvilke endringer som har skjedd i hvilken rekkefølge. Ikke tidsmessig, kun kronologisk. Høyere stater befinner seg høyere opp i treet.

Samkjøringen vil, i tillegg til at endringer fra DEFAULT flettes inn i egen versjon, frigjøre stammen for grener lavere ned på stammen. Dette er viktig i forbindelse med komprimering av versjoner. Jo flere versjoner som samkjøres med DEFAULT, jo mer stamme blir tilgjengelig for komprimeringen å dytte ned i rota.

Det er viktig å samkjøre versjoner jevnlig av tre hovedårsaker: 

1. Alltid ha oppdaterte data fra DEFAULT inne i versjonen.

2. Redusere antall potensielle konflikter, og å kunne løse disse så tidlig som mulig. 

3. Frigjøre en større del av versjonstreet for å kunne komprimeres ned i rota.

Dersom vi har versjoner som ikke har vært samkjørt på en stund, eller bare har blitt laget og deretter bare ligger i systemet, så vil disse forhindre at komprimering av geodatabasen blir så optimal som den kan. Det er slike versjoner vi kaller blokkerende versjoner (Blocking Versions) fordi de hindrer komprimeringen å bli så optimal som mulig.