Contributed by dhartmei on from the opencvs dept.
There has been quite a bit of interest from the user community in the
OpenCVS project over the past
while, and I have been thinking about writing some sort of blog entry
on the subject for some time. I guess Marco's incessant blogging has
finally gotten to me and inspired me to try to write something myself!
Since I have been hacking on the RCS parser lately, I thought
I'd write a short article about this file format which sits at the core of CVS.
head 1.3; access; symbols; locks niallo:1.3; strict; comment @# @;Following this section comes the deltas. Each entry in this section basically describes a particular revision of the file being tracked. It contains the date and time of the revision, the author, the state, sometimes branch information and a pointer to the previous revision. E.g.:
1.3 date 2006.02.27.17.07.13; author niallo; state Exp; branches; next 1.2; 1.2 date 2006.02.27.17.06.38; author niallo; state Exp; branches; next 1.1;Finally, there is the deltatext section. These contain the data corresponding to the file contents and associated commit log message at each revision. Typically, the HEAD deltatext (usually the first appearing in the file) is the complete contents of the file. All previous deltatexts contain diffs against this deltatext in a sort of reverse ed(1) format. E.g.:
d1 1 a1 1 $Id$ d3 1This deltatext demonstrates the two operations patches perform: delete, and addition. "d1 1" translates to "at line one, delete one line worth of text". Conversely, "a1 1" following by its line of data translates to "at line one, insert the following single line of text". In order to retrieve a particular revision, you typically first retrieve the HEAD revision, then calculate the final data by reverse-applying the diffs in the deltatexts up to the desired revision. Well, that's it for my short introduction to the RCS file format. Hopefully, this should illustrate why certain things can be tricky or slow in CVS/RCS, namely:
- Dealing with binary files.
- Retrieving an arbitrary revision requires parsing all previous deltas and deltatexts, thus it is not at all a random access operation.
(Comments are closed)
By cycloon (62.206.217.131) on http://cycloon.org
Comments
By daniel (82.131.15.100) on http://septum.org
feels like i'm part of "the gang" :)
keep 'em coming!
By Anonymous Coward (213.5.161.18) on
Comments
By Xavier Santolaria (158.169.131.14) xsa@ on
By Thorsten Glaser (213.196.250.125) on http://mirbsd.de/
but we have great interest in OpenCVS as well.
Currently we are using GNU CVS 1.12.13 which
contains some very interesting features such
as commitid (can be used to emulate changeset
support), but we hope OpenCVS will be ready
some time in the future to switch over.
I'm especially interested in whether the stuff
in CVSROOT/ (the scripts) will be compatible,
because we plan to do the following:
On each commit, the script which ordinarily
writes the ChangeLog entry (log_accum2 in
OpenBSD) gathers all the changed files and
creates a CTM delta which is then pushed to
the "primary anoncvs mirror". This avoids
the need to rsync every so often and gives
an additional bonus of "more" (not totally)
atomical operations.
Comments
By Anonymous Coward (128.171.90.200) on
"Stay as compatible as possible with GNU cvs"
By dingo (198.208.159.18) af.dingo@gmail.com on
Thanks a million for the update, niallo, it has inspired an extra donation from me!
Would this be the first modern concurrent versions system with a BSD license?
Comments
By Janne Johansson (130.237.95.193) on www.inet6.se
The apache license is weird too, but in a different way.
(for the APR stuff that is)
Comments
By SH (82.182.103.172) on
By Ray (199.67.138.42) on
Comments
By jfb (69.70.32.10) on
By jfb (69.70.32.10) on
I would say it's the first modern CVS period (or are you talking about versioning systems in general, in which case it is not, I think OpenCM is BSD-licensed). The GNU CVS code has become quite spaghettiish over the years and there are a lot of small bugs creeping in there, as well as a complete lack of standards with regards to style...
By Anonymous Coward (84.188.211.96) on
Or do you just re-code GNU CVS (there also many reasons to do this of course).
But I would know if OpenCVS will have any function the original CVS does not have.
Comments
By Nate (65.94.100.49) on