Slik fungerer versjonskontroll i lister og biblioteker

Når versjonskontroll er aktivert, opprettes versjoner i følgende situasjoner:

• Når et listeelement eller en fil først opprettes eller når en fil lastes opp.

  Obs!: Hvis det kreves filutsjekking, må du sjekke inn filen for å opprette den første versjonen.

• Når en fil lastes opp med samme navn som en eksisterende fil.

• Når egenskapene for et listeelement eller en fil endres.

• Når et Office-dokument åpnes og lagres. Når et dokument åpnes på nytt, opprettes en ny versjon etter at en redigering er lagret.

• Med jevne mellomrom, når du redigerer og lagrer Office-dokumenter. Ikke alle endringer og lagringer oppretter nye versjoner. Når du lagrer redigeringer ofte, for eksempel, registrerer hver nye versjon et tidspunkt i stedet for hver enkelt redigering. Dette er vanlig når automatisk lagring er aktivert.

• Når en annen bruker begynner å arbeide på dokumentet under samtidig redigering av et dokument, eller når en bruker klikker lagre for å laste opp endringer i biblioteket. 

Det kan være opptil tre gjeldende versjoner av en fil til enhver tid: den utsjekkede versjonen, den nyeste underordnede versjonen eller kladdeversjonen og den nyeste publiserte eller hovedversjonen. Alle andre versjoner regnes som historiske versjoner. Noen gjeldende versjoner er bare synlige for brukere som har tillatelse til å vise dem.

Vanligvis representerer en hovedversjon en milepæl, for eksempel en fil som er sendt inn til gjennomgang eller publikasjon, mens en underordnet versjon er et arbeid som pågår som ikke er klar for alle områdedeltakere å lese. Avhengig av hvordan teamet fungerer, kan det være mer sannsynlig at teamet trenger de nyeste underordnede versjonene, for eksempel en versjon som nylig ble redigert. Over tid kan det være mindre sannsynlig at teamet trenger en eldre underordnet versjon.

Noen organisasjoner sporer både overordnede og underordnede versjoner av filer i bibliotekene sine. Andre sporer bare hovedversjonene. Hovedversjoner identifiseres av heltall, for eksempel 5.0; underordnede versjoner identifiseres av desimaltall, for eksempel 5,1.

De fleste organisasjoner bruker underordnede versjoner når filer er under utvikling, og hovedversjoner når bestemte milepæler er nådd, eller når filene er klare for gjennomgang av et bredt publikum. I mange organisasjoner er kladdesikkerhet satt til å tillate bare eieren av en fil og personer som har tillatelse til å godkjenne filer. Det betyr at underordnede versjoner ikke kan ses av noen andre før en hovedversjon er publisert.

Lister støtter bare hovedversjoner. Hver versjon av et listeelement er nummerert med et heltall. Hvis organisasjonen krever godkjenning av elementer i en liste, forblir elementene i Ventende status til de godkjennes av noen som har tillatelse til å godkjenne dem. I ventende status nummereres de med desimaltall og kalles kladder.

Maksimalt antall underordnede versjoner er 511, og antall hovedversjoner kan justeres. Hvis du vil ha informasjon om hvordan du angir antall hovedversjoner, kan du se kontrollere hvor mange versjoner som er lagret.

Hvis du bruker en nettapp eller den nyeste skrivebordsversjonen, og du prøver å lagre en annen underordnet versjon utover det maksimale beløpet, vil du overskrive den nyeste underordnede versjonen. Hvis du bruker en gammel klient, kan du ikke lagre eller laste opp endringer i det hele tatt. Hvis du vil unngå å skrive over eller fortsette å laste opp endringer, må du publisere neste hovedversjon. Deretter kan du publisere opptil maksimalt antall underordnede versjoner på nytt for hovedversjonen. Hvis du vil lære hvordan du publiserer nye versjoner, kan du se Publiser eller opphev publisering av en versjon av en fil.

Hvis du vil ha mer informasjon om hvordan du aktiverer og konfigurerer versjonskontroll, inkludert hovedversjoner og underordnede versjoner, kan du se Aktivere og konfigurere versjonskontroll for en liste eller et bibliotek.

Versjonsnumre legges automatisk til hver gang du oppretter en ny versjon. I en liste eller et bibliotek som har hovedversjonskontroll aktivert, har versjonene heltall, for eksempel 1.0, 2.0, 3.0 og så videre. I biblioteker kan det hende at administratoren aktiverer versjonskontroll for både hovedversjoner og underordnede versjoner. Når underordnede versjoner spores, har de desimaltall som 1.1, 1.2, 1.3 og så videre. Når én av disse versjonene publiseres som en hovedversjon, blir tallet 2.0. Etterfølgende underordnede versjoner er nummerert 2.1, 2.2, 2.3 og så videre.

Når du forkaster en utsjekking, endres ikke versjonsnummeret. Hvis den nyeste versjonen var versjon 3.0, beholdes den på 3.0 etter at du har forkastet utsjekkingen.

Når du sletter en versjon, går versjonen til papirkurven, og nummeret følger med den. Versjonsloggen viser de gjenværende versjonsnumrene. De andre versjonsnumrene endres ikke. Hvis du for eksempel har et dokument som har underordnede versjoner 4.1 og 4.2, og du bestemmer deg for å slette versjon 4.1, viser den resulterende versjonsloggen bare versjon 4.0 og 4.2. Følgende bilde viser dette.

Hvis du vil ha mer informasjon om hvordan du aktiverer og konfigurerer versjonskontroll, inkludert hovedversjoner og underordnede versjoner, kan du se Aktivere og konfigurere versjonskontroll for en liste eller et bibliotek.

Du kan konfigurere hvem som kan vise kladder av listeelementer og filer. Kladder opprettes i to situasjoner:

• Når en underordnet versjon av en fil opprettes eller oppdateres i et bibliotek som sporer hovedversjoner og underordnede versjoner.

• Når et listeelement eller en fil opprettes eller oppdateres, men ennå ikke er godkjent i en liste eller et bibliotek der innholdsgodkjenning kreves.

Når du sporer hovedversjoner og underordnede versjoner, kan du angi om personer må ha tillatelse til å redigere filer før de kan vise og lese en underordnet versjon. Når denne innstillingen brukes, kan personer som har tillatelse til å redigere filen, arbeide på filen, men de som bare har tillatelse til å lese filen, kan ikke se den underordnede versjonen. Det kan for eksempel hende at du ikke vil at alle som har tilgang til biblioteket, skal se kommentarer eller revisjoner mens en fil redigeres. Hvis hovedversjoner og underordnede versjoner spores og ingen har publisert en hovedversjon ennå, er ikke filen synlig for personer som ikke har tillatelse til å se kladdeelementer.

Når innholdsgodkjenning kreves, kan du angi om filer som venter på godkjenning, kan vises av personer med tillatelse til å lese, personer med tillatelse til å redigere, eller bare forfatteren og personer med tillatelse til å godkjenne elementer. Hvis både hovedversjoner og underordnede versjoner spores, må forfatteren publisere en hovedversjon før filen kan sendes inn til godkjenning. Når innholdsgodkjenning kreves, vil personer som har tillatelse til å lese innhold, men ikke har tillatelse til å se kladdeelementer, se den siste godkjente eller hovedversjonen av filen.

Uavhengig av om personer har tillatelse til å redigere en fil eller ikke, får de ikke resultater for filen hvis de søker etter en fil som er i underordnet versjon.

Noen organisasjoner tillater ubegrensede versjoner av filer, og andre bruker begrensninger. Etter at du har sjekket inn den nyeste versjonen av en fil, kan du oppdage at en gammel versjon mangler. Hvis den nyeste versjonen er 101.0 og du legger merke til at det ikke lenger finnes en versjon 1.0, betyr det at administratoren konfigurerte biblioteket slik at det bare tillater 100 hovedversjoner av en fil. Tillegg av den 101. versjonen fører til at den første versjonen slettes. Bare versjoner 2.0 til og med 101.0 gjenstår. Tilsvarende, hvis en 102nd versjon er lagt til, bare versjoner 3.0 til 102.0 gjenstår.

Administratoren kan også bestemme seg for å begrense antall underordnede versjoner til bare de for et angitt antall av de nyeste versjonene. Hvis for eksempel 100 hovedversjoner er tillatt, kan administratoren bestemme seg for å beholde underordnede kladder bare for de siste fem hovedversjonene. Maksimalt antall underordnede versjoner mellom hovedversjoner er 511. Hvis du vil ha mer informasjon om hoved- og underordnet versjonspublisering og hva som skjer når du har mer enn maksimalt antall underordnede versjoner, kan du se delen hovedversjoner og underordnede versjoner. Hvis du vil lære hvordan du publiserer nye versjoner, kan du se Publiser eller opphev publisering av en versjon av en fil.

I et bibliotek som begrenser antall hovedversjoner som den oppbevarer underordnede versjoner for, slettes de underordnede versjonene for de forrige hovedversjonene når versjonsgrensen er nådd. Hvis du for eksempel beholder kladder for bare 100 hovedversjoner, og gruppen oppretter 105 hovedversjoner, beholdes bare hovedversjonene i de tidligste versjonene. De underordnede versjonene som er knyttet til de fem tidligste hovedversjonene – for eksempel 1.2 eller 2.3 – slettes, men hovedversjonene – 1, 2 og så videre – beholdes, med mindre biblioteket også begrenser hovedversjoner.

Å begrense antall versjoner er vanligvis en god praksis. Det betyr at du kan spare plass på serveren og redusere rot for brukerne. Men hvis organisasjonen må lagre alle versjoner av juridiske eller andre årsaker, må du ikke bruke noen begrensninger.

Hvis du vil ha mer informasjon om hvordan du aktiverer og konfigurerer versjonskontroll, inkludert grenser, kan du se Aktivere og konfigurere versjonskontroll for en liste eller et bibliotek.

• Hvis du er en Microsoft 365 kunde, aktiveres versjonskontroll automatisk når du oppretter et bibliotek eller en liste. Versjonskontroll kan deaktiveres ved hjelp av PowerShell- eller Developer API-er. Obs! Deaktivering av versjonskontroll anbefales ikke fordi det deaktiverer beskyttelse mot versjonsgjenoppretting.

• For SharePoint Server aktiveres versjonskontroll automatisk når du oppretter et bibliotek, men ikke når du oppretter en liste.

Alle som har tillatelse til å behandle lister, kan aktivere eller deaktivere versjonskontroll. På mange områder som er den samme personen som administrerer området, fordi listene og bibliotekene arver tillatelser fra området. I tillegg til å aktivere versjonskontroll, bestemmer områdeeieren (eller en annen person som administrerer listen eller biblioteket) om innholdsgodkjenning skal kreves, hvem som kan vise kladdeelementer, og om utsjekking er nødvendig. Hver av disse beslutningene har innvirkning på hvordan versjonskontroll fungerer. Hvis for eksempel personen som administrerer et bibliotek bestemmer seg for å kreve utsjekking, opprettes versjonsnumre bare når en fil er sjekket inn. Hvis innholdsgodkjenning kreves, brukes ikke hovedversjonsnumre før filene er godkjent av noen som har tillatelse til å gjøre det.

Hvis du vil lære hvordan du aktiverer versjonskontroll for en liste eller et bibliotek, kan du se Aktivere og konfigurere versjonskontroll for en liste eller et bibliotek.

Hvis versjonskontroll er aktivert i biblioteket, bestemmer personen som konfigurerer det, om det skal spores både hovedversjoner og underordnede versjoner, og bestemmer også hvem som kan se de underordnede versjonene. I de fleste tilfeller, når innholdsgodkjenning kreves, kan bare eieren av filen, og personer som har tillatelse til å godkjenne elementer, se de underordnede versjonene. I andre biblioteker kan alle som kan redigere filer i biblioteket, eller alle som har lesetillatelse til biblioteket, se alle versjoner. Når en versjon er godkjent, kan alle som har lesetillatelse til listen eller biblioteket, se versjonen.

Selv om lister ikke har overordnede og underordnede versjoner, regnes alle elementer som er i ventende status, som en kladd. I de fleste tilfeller kan bare oppretteren av elementet og personer som har tillatelsen Full kontroll eller Utforming, se kladder. En kladd vises i Ventende status for disse personene, men andre ser bare den nyeste godkjente versjonen i versjonsloggen. Hvis filen blir avvist, forblir den i ventende status til noen som har de nødvendige tillatelsene, sletter den.

Som standard er et ventende element eller en fil synlig bare for oppretteren og for personer med tillatelse til å behandle lister, men du kan angi om andre grupper med brukere kan vise elementet eller filen. Hvis biblioteket er konfigurert til å spore både hovedversjoner og underordnede versjoner, må personen som redigerer filen, først publisere en hovedversjon av filen.

Hvis du vil ha mer informasjon om hvordan du konfigurerer godkjenning for dokumenter, kan du se Kreve godkjenning av elementer i en områdeliste eller et bibliotek.

Når du sjekker ut en fil fra et bibliotek som har versjonskontroll aktivert, opprettes en ny versjon hver gang du sjekker den inn igjen. Og hvis hovedversjoner og underordnede versjoner er aktivert, kan du bestemme, ved innsjekking, hvilken versjonstype du sjekker inn. I biblioteker der utsjekking kreves, opprettes versjoner bare ved innsjekking.

I biblioteker der utsjekking ikke er nødvendig, opprettes en ny versjon første gang du lagrer etter at du har åpnet filen. Hver etterfølgende lagring overskriver versjonen du opprettet med den første lagringen. Hvis du lukker programmet og deretter åpner dokumentet på nytt, vil den første lagringen igjen produsere en versjon. Dette kan føre til at antall versjoner vokser svært raskt.

Hvis du vil ha mer informasjon om innsjekking og utsjekking, kan du se Sjekke ut, sjekke inn eller forkaste endringer i filer i et bibliotek.

Når du bruker funksjonen Vis i Filutforsker til å arbeide med filer, er det viktig å merke seg at det er en liten forskjell i virkemåten sammenlignet med å arbeide med nettleseren.

I funksjonen Vis i Filutforsker anses ikke det å gi nytt navn til en fil som utløser oppretting av en ny versjon. Det betyr at når du endrer navnet på filen via funksjonen Vis i Filutforsker, oppretter ikke SharePoint en ny versjon av filen, men gir filen nytt navn.

Når du bruker nettleseren (eller OneDrive-synkroniseringsklienten), fører det imidlertid til at du oppretter en ny versjon hvis du gir nytt navn til en ny versjon.

Hvis du trenger utsjekking, kan det hjelpe teamet med å få mest mulig ut av versjonskontrollen, fordi personer spesifikt angir når en versjon skal opprettes. En versjon opprettes bare når noen sjekker ut en fil, endrer den og sjekker den deretter inn igjen. Når utsjekking ikke er nødvendig, opprettes en versjon når noen først lagrer en fil, og denne versjonen oppdateres når personen lukker den. Hvis denne personen eller noen andre deretter åpner og lagrer filen på nytt, opprettes en annen versjon. Avhengig av situasjonen har du kanskje ikke tenkt at flere versjoner skal opprettes, for eksempel hvis du må lukke en fil for å delta på et møte før du er ferdig med å gjøre endringer i filen.

Når utsjekking kreves, kan ikke andre legge til filer, endre filer eller endre filegenskapene uten først å sjekke ut filen. Når personer sjekker inn filer, blir de bedt om å gi kommentarer om endringene de har gjort, noe som bidrar til å opprette en mer meningsfull versjonslogg.

Hvis du vil ha mer informasjon om å kreve utsjekking, kan du se Konfigurere et bibliotek til å kreve utsjekking av filer.

Lister og biblioteker har tillatelser relatert til versjonskontroll og utsjekking som varierer avhengig av tilgangsnivået som brukes for en bruker eller en bestemt gruppe. Noen som kan redigere tillatelsesnivåer, kan konfigurere disse tillatelsene på en annen måte eller opprette en ny gruppe med tilpassede tilgangsnivåer.

Disse tillatelsene gir fleksibilitet i hvordan du administrerer biblioteket. Det kan for eksempel hende du vil at noen skal kunne slette versjoner av en fil uten tillatelse til å slette selve filen. Tillatelsen til å slette versjoner er ikke den samme som tillatelsen til å slette elementer, så du kan angi et tilpasset kontrollnivå.

Tabellen nedenfor viser tillatelsene som er relatert til versjonskontroll og utsjekking, og hvilke standard tilgangsnivåer de gjelder for.

Hvis du vil ha mer informasjon om tillatelser, kan du se Forstå tilgangsnivåer.