-
Notifications
You must be signed in to change notification settings - Fork 66
/
concepts-27.htm
66 lines (66 loc) · 3.34 KB
/
concepts-27.htm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<head>
<meta name="copyright" content=
"Copyright (c) IBM Corporation and others 2000, 2005. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page.">
<meta http-equiv="Content-Type" content=
"text/html; charset=utf-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../book.css" charset="ISO-8859-1"
type="text/css">
<title>Versions</title>
<meta name="keyword" content="team">
</head>
<body style="background-color: rgb(255,255,255);">
<h1 class="Head">Versions</h1>
<p class="Para">Resources are versioned in order to capture a
snapshot of the current state of the resources at one specific
point in time. Resources in CVS are versioned by tagging them
with a version label. When a resource is versioned, it means that
a non-modifiable copy of it can be retrieved from the
repository.</p>
<p class="Intro">Versioning a project saves the line up of all
resource versions in the project. Resources other than projects
(files and folders) can be versioned. However, it is more common
to version entire projects together as the resources contained in
a project are often highly interdependent. Projects can be
versioned from the workspace or from the branch (including HEAD)
in the CVS Repositories view. The difference between these two
approaches is in deciding which child resource versions should be
part of the project version.</p>
<p class="Para">When tagging a project as a version from the
<i>Workbench</i>, the base revisions of the files in the
Workbench are tagged as belonging to that version. This is the
preferred method of versioning a project because you know exactly
which file revisions will be in the version. This operation is
allowed if you have outgoing changes or uncommitted changes.
Uncommitted changes are simply ignored and resources with
outgoing changes can still have their base revisions be part of
the version. Versioning a project with uncommitted or outgoing
changes is handy if you have to split the project at the point
where you started making changes to the resources and commit the
resources to another branch.</p>
<p class="Para">When tagging a project as a version from a
<i>branch</i> in the CVS Repositories view, you are versioning
whatever the latest resource versions are in the branch at that
moment in time. You should not version your projects from the
branch if you do not know what is committed in the branch. For
this reason, versioning from the Workbench is often
preferable.</p>
<p class="Para"></p>
<h3 class="related">Related concepts</h3><a href=
"concepts-27c.htm">CVS Repositories</a><br>
<a href="concepts-27b.htm">Branches</a><br>
<a href="concepts-17a.htm">Local history</a><br>
<a href="concepts-12.htm">Resources</a>
<h3 class="related">Related tasks</h3><a href=
"../tasks/tasks-100.htm">Creating a version of a project</a><br>
<a href="../tasks/tasks-118.htm">Versioning projects in the
repository</a><br>
<a href="../tasks/tasks-107b.htm">Enabling the CVS resource
decorations</a><br>
<a href="../tasks/tasks-105c.htm">Moving version tags</a>
<h3 class="related">Related reference</h3><a href=
"../reference/ref-47.htm">CVS</a>
</body>
</html>