GNU Info
(cvsbook.info)Revision Numbers
Revision Numbers
----------------
Each file in a project has its own revision number. When a file is
committed, the last portion of the revision number is incremented by
one. Thus, at any given time, the various files comprising a project
may have very different revision numbers. This just means that some
files have been changed (committed) more often than others.
(You may be wondering, what's the point of the part to the left of the
decimal point, if only the part on the right ever changes? Actually,
although CVS never automatically increments the number on the left, that
number can be incremented on request by a user. This is a rarely used
feature, and we won't cover it in this tour.)
In the example project that we've been using, we just committed changes
to three files. Each of those files is now revision 1.2, but the
remaining files in the project are still revision 1.1. When you check
out a project, you get each file at its highest revision so far. Here
is what qsmith would see if he checked out myproj right now and looked
at the revision numbers for the top-level directory:
paste$ cvs -q -d :pserver:qsmith@cvs.foobar.com:/usr/local/cvs co myproj
U myproj/README.txt
U myproj/hello.c
U myproj/a-subdir/whatever.c
U myproj/a-subdir/subsubdir/fish.c
U myproj/b-subdir/random.c
paste$ cd myproj/CVS
paste$ cat Entries
/README.txt/1.1.1.1/Sun Apr 18 18:18:22 1999//
/hello.c/1.2/Mon Apr 19 06:35:15 1999//
D/a-subdir////
D/b-subdir////
paste$
The file hello.c (among others) is now at revision 1.2, while README.txt
is still at the initial revision (revision 1.1.1.1, also known as 1.1).
If he adds the line
printf ("between hello and goodbye\n");
to hello.c and commit it, the file's revision number will be incremented
once more:
paste$ cvs ci -m "added new middle line"
cvs commit: Examining .
cvs commit: Examining a-subdir
cvs commit: Examining a-subdir/subsubdir
cvs commit: Examining b-subdir
Checking in hello.c;
/usr/local/cvs/myproj/hello.c,v <-- hello.c
new revision: 1.3; previous revision: 1.2
done
paste$
Now hello.c is revision 1.3, fish.c and random.c still are revision 1.2,
and every other file is revision 1.1.
Note: that the command was given as cvs ci instead of cvs commit. Most
CVS commands have short forms, to make typing easier. For checkout,
update, and commit, the abbreviated versions are co, up, and ci,
respectively. You can get a list of all of the short forms by running
the command `cvs --help-synonyms'.
You can usually ignore a file's revision number. In most situations,
the numbers are just internal bookkeeping that CVS handles
automatically. However, being able to find and compare revision numbers
is extremely handy when you have to retrieve (or diff against) an
earlier copy of a file.
Examining the Entries file isn't the only way to discover a revision
number. You can also use the status command
paste$ cvs status hello.c
===================================================================
File: hello.c Status: Up-to-date
Working revision: 1.3 Tue Apr 20 02:34:42 1999
Repository revision: 1.3 /usr/local/cvs/myproj/hello.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
which, if invoked without any files being named, shows the status of
every file in the project:
paste$ cvs status
cvs status: Examining.
===================================================================
File: README.txt Status: Up-to-date
Working revision: 1.1.1.1 Sun Apr 18 18:18:22 1999
Repository revision: 1.1.1.1 /usr/local/cvs/myproj/README.txt,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: hello.c Status: Up-to-date
Working revision: 1.3 Tue Apr 20 02:34:42 1999
Repository revision: 1.3 /usr/local/cvs/myproj/hello.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining a-subdir
===================================================================
File: whatever.c Status: Up-to-date
Working revision: 1.1.1.1 Sun Apr 18 18:18:22 1999
Repository revision: 1.1.1.1 /usr/local/cvs/myproj/a-subdir/whatever.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining a-subdir/subsubdir
===================================================================
File: fish.c Status: Up-to-date
Working revision: 1.2 Mon Apr 19 06:35:27 1999
Repository revision: 1.2 /usr/local/cvs/myproj/
a-subdir/subsubdir/fish.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
cvs status: Examining b-subdir
===================================================================
File: random.c Status: Up-to-date
Working revision: 1.2 Mon Apr 19 06:35:27 1999
Repository revision: 1.2 /usr/local/cvs/myproj/b-subdir/random.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
paste$
Just ignore the parts of that output that you don't understand. In
fact, that's generally good advice with CVS. Often, the one little bit
of information you're looking for will be accompanied by reams of
information that you don't care about at all, and maybe don't even
understand. This situation is normal. Just pick out what you need, and
don't worry about the rest.
In the previous example, the parts we care about are the first three
lines (not counting the blank line) of each file's status output. The
first line is the most important; it tells you the file's name, and its
status in the working copy. All of the files are currently in sync with
the repository, so they all say `Up-to-date'. However, if random.c has
been modified but not committed, it might read like this:
===================================================================
File: random.c Status: Locally Modified
Working revision: 1.2 Mon Apr 19 06:35:27 1999
Repository revision: 1.2 /usr/local/cvs/myproj/b-subdir/random.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
The Working revision and Repository revision tell you whether the file
is out of sync with the repository. Returning to our original working
copy (jrandom's copy, which hasn't seen the new change to hello.c yet),
we see:
floss$ cvs status hello.c
===================================================================
File: hello.c Status: Needs Patch
Working revision: 1.2 Mon Apr 19 02:17:07 1999
Repository revision: 1.3 /usr/local/cvs/myproj/hello.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
floss$
This tells us that someone has committed a change to hello.c, bringing
the repository copy to revision 1.3, but that this working copy is still
on revision 1.2. The line Status: Needs Patch means that the next
update will retrieve those changes from the repository and "patch" them
into the working copy's file.
Let's pretend for the moment that we don't know anything about qsmith's
change to hello.c, so we don't run status or update. Instead, we just
start editing the file, making a slightly different change at the same
location. This brings us to our first conflict.
automatically generated by info2www version 1.2.2.9