Xcvs is a web-based CVS tracking tool. Each commit (check-in) to a CVS
repository is viewed as one logical, coherent change. The web interface allows
one to query changes by branch, authors, dates, and etc. and view the content of
each change as a patch file.
OVERVIEW
--------
Xcvs is a web-based CVS tracking tool. Each commit (check-in) to a CVS
repository is viewed as one logical, coherent change. The web interface
allows one to query the changes by branch, author, date/time, and etc.,
and view the content of each change as a patch file.
It is possible Xcvs can be furhter expanded to view labeling and branching
events as well.
We assume CVS repository is well behaved in the following sense:
. No manual deletion or twicking of revision tags.
(Somewhat relaxed now: odd revisions may get wrong diff or no diff!)
. Deleting branch is tolerated, although change history on deleted branches
cannot be completely re-constructed. An revisions made on deleted
branches are lumped together under "ZOMBIE" branch.
. A tag always labels the whole tree of a branch that corresponds to
the snap-shot of the tree at one moment. No cross-branch check-outs,
and no out-of-order revision check-outs.
COVEATS
-------
. All date/time are in UTC time, with a copule of exceptions.
- 'cvs log' command '-d' option takes local time.
- web interface uses server localtime when a timezone is not specified
xcvs update file also stores the last update time in UTC.
. Not bother with cvs over ssh. It is just too inconvenient to be
practical.
THEORY OF OPERATIONS
--------------------
. A revision refers to one change made to one file, denoted by a file
name, the revision number after the change, author, date and log.
From these info we can derive the knowledge about the previous
revision number and branch name. Further we can identify which patchset
this revision belongs to.
Revisions are obtained while we parse through the log. They are
stored in "revision" table in database. Preivous revisions are not
retrieved into memory during each update because they are not actively
needed during update.
Since we allow LAST_UPDATE_CUSHION, it is possible we will parse some
revisions that are already in database. For this, we use two methods
to check :
. up front we figure the latest revision date/time in database.
Any revisions later than thatdate/time are indeed new ones
. for the rest, we do a live sql query to check if it is in db.
Note it is possible to have revisions earlier than last update date/time
but not in database.
----------------------------------------------------------------------
2004/05/07
Notes for v0.2.1 (beta) release
New features:
. Handle odd revisions (such as 2.1, 2.0) gracefully
. Truncate check-in comment if its size exceeds 64K in size.
Bug fixes:
. Handle non-empty "description:" field gracefully.
. Bookmark was missing two session variables (dbname and patchdir)
. Increase SQL query string size to accomodate big check-in comment.
What is next:
. Same as the last release. :)
. This version has successfully parsed some huge CVS trees such as gcc, glibc
and etc.. I think it is ready for prime time.
----------------------------------------------------------------------
2004/04/05
Notes for v0.2.0 (beta) release
New features:
. CVS_FILE_LEAD_PATH can be left empty in the config file. xcvs will
try to compute the path at run-time.
. No more xcvs work files. The misc cache info is now stored in the
database. As a result user no longer needs to specify WORK_ROOT
in the config file.
. Renamed some tables so that they all use singular forms.
. This version is not compatible with earlier versions. The protocol is
bumped to 2. You must re-generate the database and patchsets in order
to use this release.
Bug fixes:
What is next:
. Will try to gnu-lize xcvs, add man pages and etc..
. Wait for a while, and I think it is ready for v1.0.0 production release.
----------------------------------------------------------------------
2004/03/26
Notes for v0.1.3 (beta) release
New features:
. Support query patchsets by file name
. Use popen()/pclose() to execute cvs command. No more .xcvs_log .xcvs_diff
files.
. Provide an admin's option to display patchsets in reverse chronical
order, which is now the default behavior.
. Provide a way to bookmark a search (not the search results, btw)
Bug fixes:
. Handle 1.1.0.1 branch correctly. Revisions on this branch were not
expected before and would cause an assertion failure with 0.1.2.
. A patchset could contain more than one revisions of the same file.
Fixed in this release.
. When two check-in are happening almost at the same time, we might
generate more than two patchsets in 0.1.2. In this release, we
will only generate two patchsets.
. In 0.1.2 we drop revisions that are too close to cut-off time.
In 0.1.3 we drop patchsets that are too close to cut-off time
and their associated revisions. This is more correct.
What is next?
. We will break the protocol and make another beta release v0.2.0
. After that I think we are ready for v1.0.0 production release.
----------------------------------------------------------------------
2004/02/09
Notes for v0.1.2 (beta) release
What is new:
. Add "-n" command line option, which specifies to create/delete
databases. Otherwise, we can live with database created by system admin.
. We now display program name, version, database name, last update date
in the selection box.
. Add help (?) link to various search fields in the selection box.
. Date/time now takes more relaxed formats in the selection box.
. Add safe_session_start() to guard against expired session case.
. Escape file names before we do system() to make it safer.
. We now take a directory argument for '-c' option.
----------------------------------------------------------------------
2004/01/25
Notes for v0.1.1 (beta) release
First official release. System seems to be running fine on a few
installations.
The Concurrent Versions System (CVS), also known as the Concurrent Versioning
System, is an open-source version control system that keeps track of all work
and all changes in a set of files, typically the implementation of a software
project, and allows several (potentially widely-separated) developers to
collaborate. It was invented and developed by Dick Grune in the 1980s. CVS has
become popular in the open source software world and is released under the GNU
General Public License.
Features
CVS uses client-server architecture: a server stores the current version(s) of
the project and its history, and clients connect to the server in order to check
out a complete copy of the project, work on this copy and then later check in
their changes. Typically, the client and server connect over a LAN or over the
Internet, but client and server may both run on the same machine if CVS has the
task of keeping track of the version history of a project with only local
developers. The server software normally runs on Unix (although at least the
CVSNT server supports various flavors of Windows and Unix), while CVS clients
may run on any major operating-system platform.
Several developers may work on the same project concurrently, each one editing
files within their own working copy of the project, and sending (or checking in)
their modifications to the server. To avoid the possibility of people stepping
on each other's toes, the server will only accept changes made to the most
recent version of a file. Developers are therefore expected to keep their
working copy up-to-date by incorporating other people's changes on a regular
basis. This task is mostly handled automatically by the CVS client, requiring
manual intervention only when a conflict arises between a checked-in
modification and the yet-unchecked local version of a file.
If the check-in operation succeeds, then the version numbers of all files
involved automatically increment, and the CVS server writes a user-supplied
description line, the date and the author's name to its log files. CVS can also
run external, user-specified log processing scripts following each commit. These
scripts are installed by an entry in CVS's loginfo file, which can trigger email
notification or convert the log data into a Web-based format.
Clients can also compare versions, request a complete history of changes, or
check out a historical snapshot of the project as of a given date or as of a
revision number. Many open-source projects allow "anonymous read access", a
feature that was pioneered by OpenBSD. This means that clients may check out and
compare versions with either a blank or simple published password (e.g.,
"anoncvs"); only the check-in of changes requires a personal account and
password in these scenarios.
Clients can also use the "update" command in order to bring their local copies
up-to-date with the newest version on the server. This eliminates the need for
repeated downloading of the whole project.
CVS can also maintain different "branches" of a project. For instance, a
released version of the software project may form one branch, used for bug
fixes, while a version under current development, with major changes and new
features, forms a separate branch.
CVS uses delta compression for efficient storage of different versions of the
same file. The implementation favors files with many lines (usually text files)
- in extreme cases individual copies of each version are stored rather than a
delta.
Terminology
A single project (set of related files) managed by CVS is called a module. A CVS
server stores the modules it manages in its repository. Acquiring a copy of a
module is called checking out. The checked out files serve as a working copy.
One's changes to the working copy will be reflected in the repository by
committing them. To update is to acquire the latest changes from the repository
in the working copy.
History and status
CVS developed from an earlier versioning system called Revision Control System
(RCS), still in use, which manages individual files but not whole projects. Dick
Grune has provided some brief historical notes about CVS on his site. To quote:
I created CVS to be able to cooperate with my students Erik Baalbergen and
Maarten Waage on the ACK (Amsterdam Compiler Kit) C compiler. The three of us
had vastly different schedules (one student was a steady 9-5 worker, the other
was irregular, and I could work on the project only in the evenings). Their
project ran from July 1984 to August 1985. CVS was initially called cmt, for the
obvious reason that it allowed us to commit versions independently.
– Dick Grune, Dick Grune's website
The code was publicly released to mod.sources on June 23, 1986: the original
usenet post is still visible via Google Groups.
The code that eventually evolved into the current version of CVS started with
Brian Berliner in April 1989, with later input from Jeff Polk and many other
contributors. Brian Berliner wrote a paper introducing his improvements to the
CVS program which describes how the tool was extended and used internally by
Prisma, a third-party developer working on the SunOS kernel, and was released
for the benefit of the community under the GPL.
Nowadays, a group of volunteers maintains the CVS code. Notably, the development
of the Microsoft Windows version of CVS has split off into a separate project
named CVSNT and has been more active in extending the feature set of the system,
even porting the changes back to the UNIX platform under the name CVSNT.
Relationship with GNU
Historically, the relationship between CVS and the GNU project could appear
somewhat ambiguous: the GNU Web site distributed the program, labelling it "GNU
package" on one page and "other GPL-licensed project" on another. This was
recently clarified when CVS development moved from cvshome.org to
savannah.nongnu.org, with CVS officially assigned to the non-gnu category. On
the FTP site, the program has traditionally resided in the /non-gnu/ directory
and still does.
Limitations
For each commonly listed limitation of CVS there is also a commonly listed
reason:
* Moving or renaming of files and directories are not versioned. It was
implemented this way because in the past Refactoring was avoided in development
processes. More recently the thinking has changed and refactoring can be managed
by an administrator (by moving the RCS file) as it is required. If you develop
in Oracle Forms, Cobol, Fortran or even C++ then the CVS reasoning is quite
commonly accepted; if you develop with Java then the CVS reasoning may seem
counterintuitive.
* No versioning of symbolic links. Symbolic links stored in a version control
system can be a security risk - someone can create a symbolic link index.htm to
/etc/passwd and then store it in the repository; when the "code" is exported to
a Web server the Web site now has a copy of the system security file available
for public inspection. A developer may prefer the convenience and accept the
responsibility to decide what is safe to version and what is not; a project
manager or auditor may prefer to reduce the risk by using build scripts that
require certain privileges and conscious intervention to execute.
* Limited support for Unicode text files and non-ASCII filenames. Unix systems
run in UTF-8 and so CVS on Unix handles UTF-8 filenames and files natively. If
you only work on Unix systems then this response seems reasonable; however when
you work on AS/400 and Windows it may not.
* No atomic commit.
Over time, developers have wanted to change the CVS code significantly to add
new features, refactor the code and improve developer productivity. This has led
to the phrase YACC: "Yet Another CVS Clone" (itself a play on the Unix command
named, "yacc," which stands for "yet another compiler compiler"). CVS
replacement projects include CVSNT (first released 1998), OpenCVS (not released
as of 16 October 2007) and Subversion (first released 2004).
Contact Information
Call our office today to set up an appointment. Learn more about how we can
help you, and learn more about the other services that we can offer you. All
messages we receive will be answered as soon as possible. We look forward to
hearing from you.
- Electronic mail
- General Information:
