📄 unx30.htm
字号:
revisions to a prior release while still doing development. Yet another example covers how you can use source control to work on documents. Finally, you will learn how to use source control to perform simple backups of critical files.
<BR></P>
<H3 ALIGN="CENTER">
<CENTER><A ID="I4" NAME="I4">
<FONT SIZE=4><B>What Is Source Control?</B>
<BR></FONT></A></CENTER></H3>
<P>Source control refers to controlling the process of modifying software by mediating changes. It lets you control who can make changes and when. It helps to prevent conflict that could arise when many people edit the same file. It lets you save multiple
versions of a file and choose the one you would like to use. It lets you review the history of changes made to a file. It lets you save configurations, or baselines, which are lists of collections of files and revisions that are part of a common release.
<BR></P>
<P>This section introduces some of the functions of source control and the need for those functions. It helps answer the question What are the advantages of source control?
<BR></P>
<P>Normally, you want to use the most recent version of a file, but using source control gives you flexibility and the ability to examine the history of changes that went into a file. There are some important advantages to this.
<BR></P>
<P>If you are using UNIX to do software development, you may need to support older releases of your product. Using source control, you can recall the exact sources that were used to build the older release and use those files to track down and fix the
problem. After you fix the problem in the old release, you can merge the changes, as appropriate, into the current release.
<BR></P>
<P>Source control also gives you the ability to review the history of changes to a file. This is useful for almost any evolving file, be it source code or the files used to create a book.
<BR></P>
<P>You can also use source control to perform a limited personalized backup of critical files. If your system is backed up once a week and you write daily progress notes, you can check the notes into a source control system and have a safe copy in case you
accidentally erase or damage the file. This is not a replacement for doing system backups because you will still be vulnerable to system or disk problems, but it does give you finer control over recovering from your own mistakes.
<BR></P>
<P>By saving the history of revisions to a file, you give yourself the ability to analyze that history later. This can be invaluable for software projects because it gives you the ability to see the logic of each incremental change that led from the
original source to the current source.
<BR></P>
<P>The ability to recreate old versions of a single file or a group of files allows you to use source control as a simple backup system and to recover and modify earlier releases of a product or document.
<BR></P>
<P>Source control systems usually allow some form of branching (see the section "Basic Source Control Concepts") that gives you the ability to produce variants of a file. This gives you the capability to perform parallel development of two
different variants of the same file. For example, while working on the 2.0 release of your product you can produce a maintenance update to the 1.0 release of your product by modifying one or more of the source files from the 1.0 release. You can merge the
changes to the 1.0 release into the 2.0 release if you desire.
<BR></P>
<P>Source control systems are good tools for controlling all sorts of files, not just source code. This chapter was edited and produced using source control with one file containing each section. The final copy of the chapter was produced using make<B>
</B>to merge the sections together and reformat them to meet the publisher's submission guidelines. This allowed both authors to work independently to a certain extent and to merge changes after reviews.
<BR></P>
<H3 ALIGN="CENTER">
<CENTER><A ID="I5" NAME="I5">
<FONT SIZE=4><B>Basic Source Control Concepts</B>
<BR></FONT></A></CENTER></H3>
<P>Source control systems store files as a series of revisions (in SCCS they're called deltas), a set of documents that evolved from each other, as a tree. See Figure 30.1 for a generic example. Refer to this figure as you read this section on source
control concepts. Each node in the tree represents a revision of the same file.
<BR></P>
<P>
<BR><B><A HREF="30unx01.gif">Figure 30.1. A tree of revisions.</A></B>
<BR></P>
<HR ALIGN=CENTER>
<NOTE>
<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> RCS uses the term revision and SCCS uses the term delta. The two terms can be used interchangeably. This chapter uses the RCS terms except when explicitly discussing SCCS. Definitions of terms used in
RCS include the SCCS term in parenthetic comments.
<BR></NOTE>
<HR ALIGN=CENTER>
<P>The tree has a root, which is the original text of the file. In Figure 30.1, the node labeled root is the root. The trunk of the revision tree is the main sequence of revisions of the file that were derived from the root. In Figure 30.1, the node root
and all of the nodes in a straight line above it (branch_start, a_revision, and head) are the trunk of the tree. The simplest form of revision control will have only a root and a trunk. For example, if you are developing a single document and want to save
the development history, you are likely to only use the trunk for storing edits.
<BR></P>
<P>A branch occurs where a single revision has two or more revisions derived from it. In Figure 30.1, the node labeled branch_start is a trunk node that has a descendent on the trunk and a branch starting at node branch_node. Each branch and the trunk have
a head, which is the latest revision on the branch. In Figure 30.1, the nodes head and branch_head are the respective heads of the trunk and a branch. Branches are useful when you need to split into parallel development paths for your file. You will learn
more about branches in the section "Branches—Complicating the Tree."
<BR></P>
<H4 ALIGN="CENTER">
<CENTER><A ID="I6" NAME="I6">
<FONT SIZE=3><B>Interacting with Source Control</B>
<BR></FONT></A></CENTER></H4>
<P>There are several common interactions with a source control system that everyone who uses source control needs to understand.
<BR></P>
<P>In order to use a copy of a file, you need to check out (in SCCS, get) the file, or ask the source control system for a copy of a particular revision of a file. You will need to check out a file if you want to read its contents, print it out, or use it
as part of a make.
<BR></P>
<P>In order to modify a copy of a file, you need to check out with a lock (in SCCS, get for edit) to tell the source control system that you intend to make a modification to the file. See the section "Locks—Mediating Conflict" for more
information on how and why locks are useful.
<BR></P>
<P>In order to register your changes with the source control system, you need to check in (in SCCS, delta) the file. This registers your changes with the source control system and makes them available for anyone else using the source control system.
<BR></P>
<H4 ALIGN="CENTER">
<CENTER><A ID="I7" NAME="I7">
<FONT SIZE=3><B>Locks—Mediating Conflict</B>
<BR></FONT></A></CENTER></H4>
<P>Source control systems enable you to place a lock on a revision, which indicates that you intend to modify the file. This helps to prevent loss of changes when two people attempt to modify a file at the same time. For other possible solutions to this
problem, see the sections "Branches—Complicating the Tree" and "Merges—Controlling Parallel Changes."
<BR></P>
<P>Although both RCS and SCCS use locks, some source control systems do not explicitly use locks. Notably (and perhaps confusingly), the free CVS, which uses RCS for managing revisions, does not use locks; many commercial source control or configuration
management systems also do not use locks. Instead they include tools that allow you to deal with problems after the fact. This usually includes some form of automatic merging with a manual review of conflicts. The section "Merges—Controlling
Parallel Changes" describes this alternative in greater detail.
<BR></P>
<P>See Figures 30.2 and Figure 30.3 for the progression of a typical conflict.
<BR></P>
<P>
<BR><B><A HREF="30unx02.gif">Figure 30.2. Unresolved conflicting changes.</A></B>
<BR></P>
<P>
<BR><B><A HREF="30unx03.gif">Figure 30.3. Using locks to prevent conflicts.</A></B>
<BR></P>
<P>In the first time line (Figure 30.2) there is no revision locking. Arthur grabs a copy of revision root of foo and begins editing it. While he is making changes, Beverly also grabs a copy of revision root of foo and begins making her changes,
independently of Arthur. Arthur checks in his changes as revision root+a, reports to his manager that the changes are complete, and confidently flies to Belize for his two-week scuba diving vacation. Beverly checks in her changes as revision root+b, which
now contains none of Arthur's changes! Charlie, their manager, discovers that Arthur's changes are not in the weekly release and calls Arthur to find out why, completely ruining Arthur's vacation. Note that even though revision root+b is the descendent of
root+a, it doesn't contain the changes Arthur made.
<BR></P>
<P>Compare this with the second time line (Figure 30.3). Arthur grabs a copy of revision root of foo, setting a lock on that revision, and begins editing it. While he is making changes, Beverly tries to grab a copy of revision root of foo, but the source
control system informs her that the revision is locked and that she is not allowed to check it out. Beverly waits for Arthur to finish, or if her changes are urgent, she contacts Arthur to work out a way to get her changes done quickly. Arthur checks in
his changes as revision root+a, reports to his manager that the changes are complete, and blissfully flies to Australia for his four-week scuba diving vacation, on which he is spending the bonus he received for implementing a source control system for the
company. Beverly learns that foo is no longer locked and checks out revision root+a with lock. Beverly checks in her changes as revision root+a+b, which contains both her modifications and Arthur's. Charlie notices that Arthur's changes are in the weekly
release and remembers what a great thing it was that they finally implemented that source control system after Arthur's previous vacation.
<BR></P>
<H4 ALIGN="CENTER">
<CENTER><A ID="I8" NAME="I8">
<FONT SIZE=3><B>Revising the Trunk—Straight up the Tree</B>
<BR></FONT></A></CENTER></H4>
<P>Many efforts that use source control require only the use of modifications to the trunk. If your needs do not require parallel efforts (see the section "Branches—Complicating the Tree") you should be able to manage your revisions without
any of the complications introduced by branches. If you develop on the trunk, you will create an initial root revision of your file and then each time you change the file, you will check in a new trunk revision of the file.
<BR></P>
<P>See Figure 30.4 for a sample tree that uses modifications to the trunk only. In the sample tree, each revision was created by modifying the previous revision, and all modifications were done serially; there was no overlap between edits on the file.
<BR></P>
<P>
<BR><B><A HREF="30unx04.gif">Figure 30.4. Straight up the tree.</A></B>
<BR></P>
<H4 ALIGN="CENTER">
<CENTER><A ID="I9" NAME="I9">
<FONT SIZE=3><B>Branches—Complicating the Tree</B>
<BR></FONT></A></CENTER></H4>
<P>As you have learned, branches are used when you need to split into parallel modification paths for your file. Often this happens when you need to produce patches for a released version of the file (or product built using the file). It can also happen
when you wish to create a parallel track for doing a major long-term effort. For example, if you are creating an internationalized version of your application while doing development on the application itself, you might want to make the
internationalization changes on a stable base and check them in as branches. You would then merge them into the trunk development. See the section on "Merges—Controlling Parallel Changes" for information on how to merge changes from branches
back into the main trunk.
<BR></P>
<P>See Figure 30.5 for an example of a revision tree that has branches. For this project, there is a main line of development that is targeting the next product release and a branch on product development that is producing patches to the previous release.
The previous release patches are made as a branch based on the revision of the file that was released. Often, you will want to merge changes from a branch back into the trunk. See the section "Merges—Controlling Parallel Changes" for more
information on how this works. (This example will be given in greater detail in the section "A Complex Example.")
<BR></P>
<P>
<BR><B><A HREF="30unx05.gif">Figure 30.5. A revision tree with branches.</A></B>
<BR></P>
<P>RCS actually supports an even more flexible branching scheme. See "Introduction to RCS" for more information.
<BR></P>
<H4 ALIGN="CENTER">
<CENTER><A ID="I10" NAME="I10">
<FONT SIZE=3><B>Revision Numbers</B>
<BR></FONT></A></CENTER></H4>
<P>Most source control systems, including both RCS and SCCS, name revisions using revision numbers, which describe where the revision is in the tree of revisions. See Figure 30.6 for an example of how both RCS and SCCS number a revision tree. Notice that
this figure is the same tree as Figure 30.5, with revision numbers replacing the earlier names. A revision on the main trunk is identified by a pair of numbers. The release number is often used to specify an internal release number for the product. The
level number specifies which revision within a release is being referenced. The release and level numbers are there to allow a structure that has the release number incremented each time the product is released.
<BR></P>
<P>
<BR><B><A HREF="30unx06.gif">Figure 30.6. Revision numbers. </A></B>
<BR></P>
<P>Branches extend this naming structure using the same release and level as the branchpoint, the revision on which the branch is based (nodes 1.1 and 1.2 in the figure). Branches add a branch number to identify the particular branch and a sequence number
to identify the revision within the branch. The first branch from revision R.L is numbered R.L.1.1.
<BR></P>
<HR ALIGN=CENTER>
<NOTE>
<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> The terms branch and sequence for revision numbers in branches are actually from SCCS. The RCS documentation does not use specific terms here. Because RCS largely uses the same revision model as
SCCS, this chapter uses the SCCS terms.
<BR></NOTE>
<HR ALIGN=CENTER>
<H4 ALIGN="CENTER">
<CENTER><A ID="I11" NAME="I11">
<FONT SIZE=3><B>Merges—Controlling Parallel Changes</B>
<BR></FONT></A></CENTER></H4>
<P>You may also be effectively performing parallel development by releasing your files (rather than access to the source control system) to other people. This can happen when you send out preliminary versions of a document for review or when you do a
release of the source code for a project or product. After you have made your own postrelease changes, you may find that people with access to the released files suggest changes to you. One way to deal with this is to use merge facilities of your source
control system, which support merging sets of changes that have a common base.
<BR></P>
<P>See Figure 30.7 for an example of parallel revisions and merging them. In this example, instead of using a source control system you use the merge command. Many source control systems use merge or a similar program to perform the merging task. If your
source control system does not explicitly support merges, you can use the merge command to perform merges manually.
<BR></P>
<P>
<BR><B><A HREF="30unx07.gif">Figure 30.7. Merging parallel changes. </A></B>
<BR></P>
<HR ALIGN=CENTER>
<NOTE>
<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> The source for merge is included in the RCS package on the CD-ROM. If your system doesn't have merge, you may want to install merge even if you don't plan to use RCS.
<BR></NOTE>
<HR ALIGN=CENTER>
<P>For this example, you should create three files, called base, revmain, and revbranch. The first is the base from which both of the others are created. The common ancestor revision is needed so the merge program can determine the changes from base to
revbase and from base to revmain and merge the changes together. The file base should contain the following:
<BR></P>
<PRE>A line in the base file
Another line in the base file
A third line in the base file
The final line of the base file</PRE>
<P>The file revmain should contain the following:
<BR></P>
<PRE>A line in the base file
A line added in revmain
Another line in the base file
A third line in the base file
The final line of the base file</PRE>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -