Introduksjon

Versjonshåndtering

Versjonshåndtering kan være vanskelig hvis det ikke styres på riktig måte. Versjonskontrollmekanismen har utallige muligheter, men det er lurt å dekke dem med en slags ytterligere logikk. 

Da kan faktisk versjonshåndtering utføres i kulissene og vises for brukeren som en slags logisk arbeidsflyt. 

HyperDoc antar at det finnes et hovedarkiv som brukes som offisielt repositorium, og et hvilket som helst antall utkast kan opprettes av brukere, deles og publiseres eller forkastes.

HyperDoc-versjonen inneholder kun endringssett – derved dupliseres faktisk ingen data. Et objekt som er opprettet i én versjon vil finnes i databasen så lenge det ikke slettes. Versjonen som objektet ble slettet i, vil angi "slutten på levetiden" til objektet. Hvis en bruker går tilbake til forrige versjon, vil objektet være synlig der. 

Eksempler på brukertilfeller

Oppdateringer under en bygnings livssyklus: i et ikke-versjonbasert system lages alle oppdateringer på stedet, som overskriver eventuelle historiske data (dataoppdatering, etasjeplanendring, solgte eiendommer, osv.). Systemet tillater ikke å publisere nært forestående planer og data slik at de er tilgjengelige parallelt med gjeldende data. En bruker av et nytt system skal være i stand til å arbeide parallelt med historiske, gjeldende og fremtidige planer og data.

Prosjekterte alternative oppsett og bygningsplanlegging En bruker skal være i stand til å lagre alternative oppsett for prosjektering og presentasjon. Denne operasjonen må ikke påvirke hovedarkivet som brukes i det daglige arbeidet og vedlikeholdet av eiendommene. Det skal være tillatt for FM-systemer å samhandle med slike alternative versjoner for simuleringer og rapporter.

Rapportering i versjonssammenheng: En bruker må være i stand til å opprette rapporter som gjenspeiler endringer i eiendomsarkiv i løpet av en valgt tidsperiode. (Tilgjengelig areal for hvert kvartal, antall eiendommer, osv.)

Modiene Streng og Avslappet versjonskontroll

Modusen Streng versjonskontroll tillater kun å foreta endringer i data i arbeidsutkast. Publiserte versjoner kan i motsetning til utkast ikke endres på noen måte. Denne modusen krever at en ny versjon blir publisert hver gang en dataendring er nødvendig. Full revisjonssporing utføres i denne modusen for hver publisert versjon som en minste enhet som spores. Endringer som utføres i en redigeringsøkt i et utkast, spores ikke (det utføres i stedet etterfølgende endringer som overskriver tidligere verdier som er lagt inn i det samme utkastet). 
Modusen Avslappet versjonskontroll tillater kun å opprette versjoner når det er nødvendig, og publiserte versjoner er ikke "lukket". Redigering kan utføres i valgte versjon og overskriver eksisterende informasjon. Kun informasjonen om den seneste endringen lagres. 

Utkast er ganske enkelt "arbeidskopier" av hele databasen fra brukerens synspunkt, men faktisk dupliseres ingen data, så databasevekst begrenses til det nødvendige minimum (kun trinnvise endringer blir lagret). 
Når REST API brukes til å sette inn, oppdatere og slette, må objekter og dokumenter i riktig versjon foreligge. 

Termer for versjonskontroll

1. Versjon – versjoner brukes for å håndtere endring i hvert element som er lagret i HyperDoc-databasen.

   1. Versjonskontroll omfatter objekter med deres egenskaper, dokumenter, koblinger, osv.

   2. En ny versjon opprettes etter hver endring (redigering).

   3. Ingenting slettes for godt i systemet. Ny versjon opprettes som ikke inneholder det slettede objektet.

   4. Ved å endre ett objekt oppnår man formelt sett en ny versjon av hele systemet, men uten å duplisere unødvendige data. Andre uendrede objekter er representert i deres seneste versjon, og sørger på denne måten for en sammenhengende visning av hele verdenen – følgelig vil Multiple Worlds Framework bli brukt til å beskrive hele sett med funksjoner.

2. Alternativ – alternativer brukes til prosjektering eller utkast. Denne termen er ikke direkte tilgjengelig for sluttbrukeren. I de fleste tilfeller betyr det faktisk "alternativ versjon" når det finnes flere versjoner i systemet som er like viktige. I brukergrensesnitt vil alternativer bli brukt for å opprette personlige utkast eller lagre fremtidige versjoner av arkivet.

3. Etikett – etiketter er faktisk versjoner som brukere kan få tilgang til. Etikett viser til viktig versjon i systemet. Det kan være mange endringer mellom etiketter (lavnivåversjoner) som er lagret for revisjonsspor og angreoperasjoner.

4. Gjeldende versjon – dette er en markør som kan brukes for å lagre spesifikk versjon valgt av administrator. Dette kan dessuten anses som standardversjon, dvs. den som er synlig i systemet etter oppstart, og gjenspeiler verdenens gjeldende tilstand.

5. TIP – dette er en markør som brukes for å godta nye alternative versjoner inn i hovedgrenen Versjoner aksepteres, men de blir ikke gjeldende samtidig. Det kan anses som å plassere versjoner i rekkefølge. Denne termen er heller ikke synlig for sluttbrukeren. Å stille inn TIP i versjonskontrollsystem vil bli utført i kulissene av brukerfunksjoner som f.eks. "publiser endringer".

(Detaljerte scenarioer for versjonshåndtering samt brukertilfeller beskrives i separate dokumenter.)

Utkast (alternativer)

HyperDoc-alternativer er uavhengige alternative versjoner av systemet. Det er likevel noen avhengigheter mellom objekter i hovedarkiv og utkast.

Opprette et utkast

Når et utkast skal opprettes, må du velge hvilken versjon som skal være utgangspunktet for dette utkastet. I eksempeldiagrammet er Utkast A1 avledet fra Hovedarkivversjon V2, og alle objekter i A1 vil derfor ha den samme starttilstanden som i V2.  Brukeren kan modifisere eksisterende objekter eller legge til nye objekter. Alle endringer er kun synlige i dette utkastet og vil ikke påvirke objekter i V2 eller V3.

A2 representerer et øyeblikksbilde i et utkast - det kan anses som en "lagre tilstand"-operasjon som vil skille mellom endringer som er gjort før og etter at et øyeblikksbilde ble tatt.  

Hvis arkivet arbeider i en avslappet modus, er endringer på stedet for hver versjon tillatt. Dette kan føre til flere konflikter. Hvis for eksempel en bruker velger å slette et objekt i A1 som opprinnelig ble lagt til i V2 , vil det ikke være mulig å slette dette objektet i V2. En hensiktsmessig varselmelding vil bli vist til brukeren, som angir at valgte objekt allerede er modifisert (slettet) i fremtidige versjoner. 

Forkaste et utkast

Hvis du forkaster et utkast, fjernes alle endringer som er gjort i utkastet fra systemet for godt. Det finnes ingen indikasjon på at utkastet fantes.

Publisere et utkast

Å publisere et utkast betyr at en bruker ønsker å slå sammen endringer som er gjort i utkastet med hovedarkivet. Det finnes forskjellige muligheter, men den gjeldende implementeringen har kun én publiseringsmodus som vil:

1. Gjøre alle endinger som er gjort i utkastet flate til én versjon (ingen øyeblikksbilder)

2. Opprette en ny versjon av hovedarkivet som vil inneholde dette endringssettet.

3. Forkaste utkastet

Enkelt versjonstre med ett alternativ (utkast)

Open