working with versioning in sharepoint services...working with versioning topics came directly from...

Working with Versioning Topics came directly from Microsoft SharePoint Services Help.

ICT Training, Maxwell School of Syracuse University

Working with Versioning in

SharePoint Services Table of Contents

INTRODUCTION TO VERSIONING ............................................................................................................. 1

ABOUT ENABLING AND CONFIGURING VERSIONS FOR A LIST OR LIBRARY ......................................................... 2

ABOUT MANAGING MAJOR AND MINOR VERSIONS ............................................................................................. 2

OTHER SETTINGS THAT AFFECT VERSIONING ..................................................................................................... 3

Content approval ............................................................................................................................................ 3

Requiring check out ........................................................................................................................................ 3

Specify who can see draft items ..................................................................................................................... 3

List or library permissions .............................................................................................................................. 5

WHEN VERSIONS ARE CREATED ......................................................................................................................... 5

WORKING WITH MAJOR AND MINOR VERSIONS ................................................................................ 5

VERSION NUMBERING......................................................................................................................................... 6

CONTROL HOW MANY VERSIONS ARE STORED ................................................................................................... 6

Enable versioning ........................................................................................................................................... 7

HOW VERSIONING WORKS WITH CONTENT APPROVAL ....................................................................................... 8

Require content approval in a list or library ................................................................................................... 9

Approve or reject items or files in a list or library ......................................................................................... 9

HOW VERSIONING WORKS WITH FILE CHECK OUT ............................................................................................ 10

Require check out for files in a library ......................................................................................................... 11

RESTORE OR DELETE A PREVIOUS VERSION OF AN ITEM OR FILE ..................................................................... 11

Restore a previous version............................................................................................................................ 12

Delete a previous version ............................................................................................................................. 12

Delete all previous versions ......................................................................................................................... 13

Delete all minor versions .............................................................................................................................. 13

Introduction to versioning

Versioning enables you to store, track, and restore items in a list and files in a library as they are changed.

When versions are tracked for lists or libraries, revisions to the items or files and their properties are stored.

This enables you to better manage content as it is revised and even to restore a previous version — for

example, if you make a mistake in the current version. Versioning is especially helpful when several people

work together on projects, or when information goes through several stages of development and review.

Versioning is available for list items in all default list types — including calendars, issue tracking lists, and

custom lists — and for all file types that can be stored in libraries — including Web Part Pages.

You can use versioning to do the following:

Record a version history: When versioning is enabled, you can see when an item or file was changed and

who changed it. You can also see when properties, or information about the file, were changed. For

example, if someone changes the due date of a list item, that information appears in the version history.

For files, you also see comments that people include about their changes.



Restore a previous version as your current version: Did you make a mistake in a current version? Or

perhaps you need to restore part of a document that you deleted. You can easily replace your current

version with a previous version. Your current version then becomes part of the version history.

View a previous version: You can view a previous version without overwriting your current version. For

.aspx files, you can view only details about the changes that were made to the files, and not the actual

pages that the files create.

Libraries can track both major versions, such as those to which a new section was added; and minor versions,

such as those in which a spelling error was corrected. Lists can track only major versions. Lists and libraries

can also limit the number of versions that people can store.

To enable versioning, you must have permission to design a list or library.

About enabling and configuring versions for a list or library When you track versions of files or list items, each version is numbered and saved as part of a version history.

People in your organization can view the version history and recover earlier versions if needed. You can

configure several settings that affect versioning, including which type and how many versions to retain. You

can also configure settings that interact with versioning, such as requiring content to be approved or files to be

checked out.

Versioning in lists and libraries enables you to track and manage information as it evolves and to view and

recover earlier versions if necessary. In lists, all versions are tracked in the same way. In libraries, you can

specify whether to track all versions in the same way or specify that some versions are major, such as those in

which a new chapter is added to a manual, and some are minor, such as those in which a spelling error is

corrected.

To help manage storage space, you can specify the number of versions that you want to store. Limiting the

number of versions can help you to manage server space, as well as prevent the version history from

becoming too cumbersome to be useful. People can overwrite a previous minor version with an existing

version, if they don't want to clutter the file's history with lots of minor changes.

About managing major and minor versions If your organization usually produces many drafts of files, tracking both major and minor versions can be

beneficial. People can differentiate between the levels of changes that they make and communicate when a file

has reached a stage in which they want other people to view it. For example, when your department is

working on a manual, you and your team members may want to designate versions as major when a new

section is added and designate versions as minor while the content is drafted.

Tracking both kinds of versions also helps make the version history more meaningful. For example, a major

version is more likely to represent a milestone in the file's development, such as a file being submitted for

review or being distributed to others. A minor version is typically a routine increment, such as a version that

you save or check in while you are still writing the content, or a version in which you correct some minor

errors.

When major and minor versions are being tracked, a version is stored by default as a minor version, unless

you designate the version as major. When someone saves a file and closes it, the version is tracked as a minor

version; the file must be published to become a major version. If an author checks out a file and checks it back

in, the author is prompted to choose whether to check in a major version or a minor version.



When you configure versioning at the time when you create a list or library, simple versioning is enabled by

default, and you don't have the option of enabling major and minor versioning. However, you can specify

additional settings later.

Other settings that affect versioning You can configure other settings that affect versioning. In lists or libraries, you can require content to be

approved — this setting is sometimes referred to as content moderation. In libraries, you can require files to

be checked out, which helps to avoid conflicts over changes and prompts people to enter comments about files

when they check them in.

Content approval When content approval is required, a list item or file remains in a draft or pending state until it is approved or

rejected by someone who has permission to approve it. If the item or file is approved, it is assigned an

Approved status in the list or library, and it is displayed to anyone with permission to view the list or library.

If the item or file is rejected, it remains in a pending state and is visible only to the people with permission to

view drafts.

When you enable major and minor versioning in a library that requires content approval, you can also add a

workflow, if you or someone in your organization has created one. A workflow controls how your files move

through business processes, such as review or approval. You can use a workflow to manage the approval

process when major versions are checked in.

By default, a pending item or file is visible only to its creator and to the people with permission to manage

lists, but you can specify whether other groups of users can view the item or file. If your library is set up to

track both major and minor versions, the person who edits the file must first publish a major version of the

file.

Requiring check out Requiring check out can help your team make the most of versioning because people specifically designate

when a version is to be created. A version is created only when someone checks out a file, changes it, and then

checks it back in. When check out is not required, a version is created when someone first saves a file and this

version is updated when the person closes it. If that person or someone else then opens and saves the file

again, another version is created. Depending on the situation, you might not intend for multiple versions to be

created, for example, if you have to close a file to attend a meeting before you finish making changes to the

file.

When check out is required, people cannot add files, change files, or change the file properties without first

checking out the file. When people check in files, they are prompted to provide comments about the changes

that they made, which helps to create a more meaningful version history.

Specify who can see draft items You can control which groups of people can read drafts of list items and files. Drafts are either the minor

versions of files or the list items or files that are not yet approved. A draft can be a new item or an item that

has changed.

You can configure who can view drafts of list items and files. Drafts are created in two situations:

When a minor version of a file is created or updated in a library that tracks major and minor versions

When a list item or file is created or updated but not yet approved in a list or library in which content

approval is required



When you track major and minor versions, you can specify whether people must have permission to edit files

before they can view and read a minor version. When this setting is applied, people who have permission to

edit the file can work on the file, but those who have permission only to read the file cannot see the minor

version. For example, you may not want everyone who has access to your library to see comments or

revisions while a file is being edited. If major and minor versions are being tracked and no one has published a

major version yet, the file is not visible for people who do not have permission to see draft items.

When content approval is required, you can specify whether files that are pending approval can be viewed by

people with permission to read, people with permission to edit, or only the author and people with permission

to approve items. If both major and minor versions are being tracked, the author must publish a major version

before the file can be submitted for approval. When content approval is required, people who have permission

to read content but do not have permission to see draft items will see the last approved or major version of the

file.

For example, you may want to restrict users who are not part of the approval process from seeing documents

that contain speculative information prior to a major announcement, or your organization may require that

certain files are confidential. In such cases, you should accept the default restrictions. On the other hand, you

may want to use content approval to specify the status of a list item or file but not necessarily control access to

it while it is being revised. For example, you might want people who read a file to know that it is a draft that

could change, because it is not yet approved, but you don't want to prevent people who visit your site from

reading the file. In this case, you can enable anyone who has permission to read items in the list or library to

view drafts.

You can specify which groups of people can view drafts of files. This setting can be different from the setting

for the group of people who can view the rest of the items in your list or library, such as the major versions of

files or the files or list items that are approved.

To specify who can view drafts, you must have permission to design a list or library.

The following procedure applies only to libraries that track both major and minor versions and lists or libraries

that require content approval.

1) If the list or library is not already open, click its name on the Quick Launch.

a) If the name of your list or library does not appear, click View All Site Content, and then click the

name of your list or library.

2) On the Settings menu , click List Settings, or click the settings for the type of library that you

are opening.

a) For example, in a document library, click Document Library Settings.

3) Under General Settings, click Versioning settings.

4) In the Draft Item Security section, under Who should see draft items in this list or under Who should

see draft items in this document library, click the group of users whom you want to enable to view

drafts.

a) The option for users who can approve items is available only if your library requires content approval.

5) Click OK.



List or library permissions Lists and libraries have permissions related to versioning and check out that vary depending on the permission

level that is applied to a user or a specific group. Someone who can edit permission levels can configure these

permissions differently or can create a new group with customized permission levels.

These permissions enable flexibility in how you manage your library. For example, you may want someone to

be able to delete versions of a file without having permission to delete the file itself. The permission to Delete

Versions is not the same as the permission to Delete Items, so you can provide a customized level of control.

When versions are created When versioning is enabled, versions are created in the following situations:

When a list item or file is first created or when a file is uploaded.

Note: If file check out is required, the file must first be checked in, in order to create its first version.

When a file is uploaded that has the same name as an existing file and the Add as a new version to

existing files check box is selected.

When the properties of a list item or file are changed.

When a file is opened, edited, and saved. A version is created when you first click Save. This version is

updated with the latest changes that you make to the file before closing it.

Note: A version is not created every time that you or another user clicks Save, because this would create

too many versions.

When a file is checked out, changed, and then checked back in.

Note: If you or another user discards the checked-out version, no version is created.

You can choose to delete a single version of a file (for example, if you know that you made a mistake in that

version) which removes that version from the version history. However, if you delete the actual file, all of its

versions are deleted with it. By default, when you delete a version, the version is sent to the Recycle Bin,

where it can be recovered until it is permanently deleted.

Important: If your organization limits the number of versions that it stores, the oldest versions are

permanently deleted when the limit is reached. They are not sent to the Recycle Bin.

Working with major and minor versions

Depending on the needs of your organization, your library may be set up with simple versioning, which tracks

only major versions, or it may track both major and minor versions. If people in your group don't often work

on several revisions, your organization may only need simple versioning. If many people work on files

together and usually create several versions, your organization may want to track both major and minor

versions.

Providing two types of versions can help your team to better manage its content. People who work with the

content can better understand the current status of a file. For example, a major version is usually one that is

ready for a larger group to see and review, whereas a minor version is a draft that someone is still working on.

Tracking both kinds of versions also helps to make the version history more meaningful. A major version is

more likely to represent a milestone in the file's development, such as when a file is submitted for review or

distributed to others. A minor version is typically used as a routine increment, such as a version that you save

or check in while you are still writing the content, or a version in which you correct some minor errors. When



you want to view the version history of a file, the major versions may help you to identify the stages of the

file's development and make the history easier to browse through.

When major and minor versions are tracked, a version is stored by default as a minor version, unless you

designate the version as a major version. When you save a file and close it, the version is tracked as a minor

version. You must first publish the file in order for it to become a major version. You can publish the file by

using drop-down commands in a library. In some programs that are compatible with Microsoft Window

SharePoint Services, you can also use commands in the program. By default, each major version can have up

to 511 drafts (minor versions), but the site administrator or owner can further limit the number of versions.

If you have permission to delete versions, you can overwrite a minor version with another minor version. For

example, you may want to overwrite a version if you know that the previous version contains an error and you

don't need to keep it. If you publish a major version and then realize that you made a mistake, you can turn the

version into a minor version again by unpublishing it.

If you check out files before working on them, you can designate which type of version you are checking in.

You do not have to publish a file if you designate it as a major version when you check it in.

Version numbering Versions are numbered as you create them. In a list or in a library with simple versioning enabled, version 1 is

the first version that you create or upload, and the version number increases by increments of whole numbers,

as in version 2, version 3, and so on.

When you track major and minor versions, the major versions are whole numbers, and the minor versions are

decimals. For example, 0.1 is the first minor version of a file, 1.3 is the third minor version of a file that was

published once, and 2.0 is the second major version of a published file.

The current published major

version is highlighted, and the

version number is a whole number.

A version is created when

properties or metadata changes.

The first version of a file is

always minor version number 0.1.

Control how many versions are stored You can limit how many versions of list items or files are saved in a list or library, which can help to preserve

server space. If your team creates a large number of versions, limiting the number of versions may help your

team to better manage and locate previous versions. For example, if your team keeps a large number of

versions over several months or years, it may be difficult for members to browse through the version history

to find the versions that they need. If your team needs to view or retain any of its previous versions, either do

not limit the number of versions to keep or set the number of versions that you keep to a high number.

If your library tracks major and minor versions, you can choose how many major versions of files to keep and

how many major versions to keep the minor versions for. By default, each major version can have up to 511

drafts (minor versions).



Depending on the way your team works, your team may be more likely to need its most recent minor versions.

Over time, your team may be less likely to need an older minor version. Usually, a major version represents a

milestone, such as a file submitted for review or publication, whereas a minor version is a work in progress

that isn't ready for all site participants to read.

If a list or library limits the number of major versions, the earliest versions are deleted when the limit is

reached. For example, if only 20 versions are retained, and your team creates 25 versions, only versions 6

through 25 are kept. If another version is created, only versions 7 through 26 are kept. If your list or library

limits versions, you should make sure that contributors are aware that earlier versions will be deleted when the

version limit is reached.

Important: If your organization limits the number of versions that it stores, the oldest versions are

permanently deleted when the limit is reached. They are not sent to the Recycle Bin.

In a library that limits the number of major versions that it keeps minor versions for, the minor versions are

deleted for the previous major versions when the version limit is reached. For example, if you keep drafts for

only 10 major versions, and your team creates 15 major versions, only the major versions will be kept for the

earliest versions. The minor versions that are associated with the five earliest major versions — such as 1.2 or

2.3 — are deleted, but the major versions — 1, 2, and so on — are kept, unless your library also limits major

versions.

Enable versioning 1) If the list or library is not already open, click its name on the Quick Launch.




are opening.



4) Do one of the following:

a) For list items, to specify that versions are tracked, click Create a version each time you edit an item

in a list in the Item Version History section.



b) For files, to specify that only one type of version is tracked, click Create major versions in the

Document Version History section.

c) For files, to specify that both major and minor versions are tracked, click Create major and minor

(draft) versions in the Document Version History section.

5) You can specify how many versions of items or files to keep. Do one of the following in the Item Version

History section or Document Version History section:

a) To specify the number of versions of list items that are stored, select the Keep the following number

of versions check box, and then type the number of versions that you want to keep.

b) To specify the number of major versions of files that are stored, select the Keep the following number

of major versions check box, and then type the number of major versions that you want to keep.

c) To specify the number of major versions to keep the drafts for, select the Keep drafts for the

following number of major versions check box, and then type the number of major versions that you

want to keep drafts (minor versions) for.

6) Click OK.

In a list or library, you can display a Version column that displays the version number of files or list items,

which can be helpful if your team frequently revises information.

How versioning works with content approval Major and minor versioning integrates with content approval for lists and libraries.

When content approval is required, a list item or file remains in a draft or pending state until it is approved or

rejected by someone who has permission to approve it. If the item or file is approved, it is assigned an

Approved status in the list or library, and it is displayed to anyone with permission to view the list or library.

If the item or file is rejected, it remains in a pending state and is visible only to the people with permission to

view drafts.

When you enable major and minor versioning in a library that requires content approval, you can also add a

workflow, if you or someone in your organization has created one. A workflow controls how your files move

through business processes, such as review or approval. You can use a workflow to manage the approval

process when major versions are checked in.

By default, in a library that tracks both major and minor versions, you must first publish a major version of a

file before it can be approved. Minor versions are considered drafts that are still being developed, so they don't

appear as pending items that are waiting for approval.

For example, a travel agency might use a document library to manage files. While team members develop a

new sales proposal, they track minor versions of the file. If they make a mistake in one version, they can

restore it to a previous version. When they finish the proposal, they can create a major version and then



publish it for approval by their legal department and their manager. When the file is approved, other

employees in the company can view the file.

By default, a pending item or file is visible only to its creator and to the people with permission to approve

items, but you can specify whether other groups of users can view the item or file.

When content approval is required, the people who have permission to read content but who do not have

permission to see draft items will see the last approved or major version of the list item or file. If major and

minor versions are tracked in a library and no one has published a major version yet, the file will not be

visible for the people who do not have permission to see draft items.

Require content approval in a list or library 1) If the list or library is not already open, click its name on the Quick Launch.




are opening.



4) In the Content Approval section, under Require content approval for submitted items?, click Yes.

5) Click OK.

Approve or reject items or files in a list or library

You can specify that approval for a document is required in a library or list.

When this content approval setting is applied, an item or file that has been changed remains

in a pending state until it is approved or rejected by someone who has permission to

approve it.

If the item or file is approved, it is assigned an Approved status in the list or library, and it

is displayed to anyone with permission to view the list or library. If the item or file is rejected, it remains in a pending state and is visible only to the people with permission

to view drafts.

By default, a pending item or file is visible only to its creator and to the people with permission to manage

lists, but you can specify whether other groups of users can view the item or file.

If your library is set up to track both major and minor versions, the person who edits the file must first publish

a major version of the file.



1) If the list or library is not already open, click its

name on the Quick Launch.

a) If the name of your list or library does not

appear, click View All Site Content, and then

click the name of your list or library.

2) Point to the item or file to display a down arrow.

3) Click the down arrow, and on the menu that

appears, click Approve/reject

4) In the Approval Status section, choose whether you want to approve or reject the item.

5) In the Comment section, you can optionally type a comment about why the item was approved or rejected.

6) Click OK.

Notes:

If the content approval setting is applied to a list or library that already contains items or files, approval is

required for any new content or for changes that you make to existing content. Existing items or files are

treated as approved, but you can change their status later.

If the content approval setting is disabled on a list or library that previously required approval, any pending

or rejected items become visible to all viewers, unless they were deleted.

How versioning works with file check out Checking out files make the most of versioning. When you check out a file, a version is created only when

you check the file back in, so that you can specifically designate when a version is created. When check out is

not required, a version is created when you first save a file, and then this version is updated when you close it.

If you open and save the file again, another version is created. Depending on the situation, you might not

intend for multiple versions to be created, for example, if you have to close a file to attend a meeting before

you finish making changes to the file.

When check out is required, you cannot add a file, change a file, or change the file's properties without first

checking out the file. When you check in the file, you are prompted to provide comments about the changes

that you made, which helps to create a more meaningful version history.



Require check out for files in a library Requiring check out prevents multiple people from making changes at the same time, which can create

conflicts over changes and lead to confusion.

When someone creates a new file or adds a new file to a library that requires check out, the file is initially

checked out. The person who creates or adds the file must check it in before other people can see it. Check out

is also required to update information about the file, such as the title or when the file is due.

When check out is required, a file

is checked out automatically

when someone opens it for

editing, unless it is already

checked out. The editing

commands notify the user that the

file is being checked out. For

example, if you click the Edit in

Application command on the

shortcut menu for a file, you see a

message that the file is being

checked out.

When you check out a file from some programs that are compatible with Windows SharePoint Services, you

can work with the file on your hard disk, even when you are disconnected. The copy is stored in your server

drafts folder, which is, by default, the SharePoint Drafts folder in your My Documents folder. However, you

can change the location in some client programs. Working on files on the hard disk is frequently faster than

working with files on the server and enables you to easily continue working while you are away from the

office.

When a file is checked out, no one can edit it except

the person who checked it out. Its icon in the library

changes to indicate that the file is checked out .

When you rest the mouse pointer on the checked-out

icon, the name of the person whom the file is checked

out to appears in a ScreenTip.

Changes that someone makes to a file while it is checked out are not visible to others until the file is checked

back in. This is true regardless of whether the person is working on the file on their hard disk or on the server.

When you check in a file, you are prompted to enter comments about the changes that you made. If a library

tracks versions, the comments become part of the version history. If both major versions and minor versions

are tracked, you are prompted to choose which type of version you are checking in.

Restore or delete a previous version of an item or file If your list or library tracks versions, you can restore or delete a previous version of a list item or file.

When you track versions of items in a list or of files in a library, a version history is created. A version history

enables you to see how a file evolved and to view, restore, or delete a previous version. Being able to manage

the version history provides flexibility in how your team manages its authoring and editing processes.

username



For example, if you make a mistake in the current version, you can restore a previous version. If you know

that you don't want to keep a certain version — for example, if it contains an error or if the version history is

growing too long — you can delete that previous version. To delete versions, you must have permission to

contribute to a list or library. Note also that an administrator can create custom permissions for deleting

versions.

If your team makes many changes to its files, the version history can grow long. Storing many versions can

occupy a lot of space on the server and make it harder to see important changes in the version history. To

simplify the version history, you can delete some versions that you no longer need. If you don't want to keep

any previous versions, you can delete them all at once. When you delete a version, it is sent to the Recycle

Bin, where it can be recovered by someone with permission to recover items.

Lists and libraries can also be configured to limit the number of versions that are saved for each list item or

file. If your list or library has a version limit, your team may want to delete the versions that it doesn't need to

ensure that it can retain the versions that it does need.

If major and minor versions are being tracked for the list or library, you can delete just the minor versions.

Deleting minor versions can help save space on the server and make it easier to find the important versions,

such as the version that was submitted for review or published for other people to see. When you delete all

minor versions, any version with a decimal point, such as 1.2 or 2.3, is deleted.

Restore a previous version Use this procedure to select a previous version from the version history and restore that version as your

current version.




2) Point to the item or file for which you want to manage versions, click the arrow that appears, and then

click Version History.

a) Versions are numbered and listed in reverse

order, with the latest version first.

3) Point to the version that you want to restore, click

the arrow that appears, and then click Restore.

4) When you are prompted to confirm whether you want to restore the version as your current version, click

OK.

Delete a previous version Use this procedure to delete a previous version of a file from the version history.

Note: You cannot delete just the current version of a file without permanently deleting the file and all versions

of it. If you make a mistake in the latest version and you want to delete it, you must first restore a previous

version and then delete the version that contains the mistake. Or, if you have the file checked out, you can

discard the changes in the current version by undoing the check-out.








a) Versions are numbered and listed in reverse order, with the latest version first.

3) Point to the version that you want to delete, click the arrow that appears, and then click Delete.

4) When you are prompted to confirm the deletion, click OK.

When you delete a version, it is sent to the Recycle Bin, where it can be recovered by someone with

permission to recover items.

Delete all previous versions When you delete all previous versions of list items or files, all versions except the current version are sent to

the Recycle Bin. If you delete versions in a library that tracks both major and minor versions, and your current

version is a minor version, the last published major version is also kept.







3) Click Delete All Versions.

4) When you are prompted to confirm whether you

want to delete all previous versions, click OK.

Delete all minor versions This procedure is available for libraries that track major and minor versions of files. If your current version is

a minor version (or if there are no major versions), the current minor version is kept when you delete all minor

versions.







3) Click Delete Minor Versions.

4) When you are prompted to confirm whether you want to delete all minor versions, click OK.