RE: Code-wise, How Does CVS Do Versioning?

[Wiest, Damian]

I should probably let those more qualified answer this question, but I'll
take a shot at describing the repository file format.  First off, take a
look in the Cederqvist, I believe it discusses this topic.

If you take a look at a ,v file in a CVS repository, you'll see that it
consists of the following:

 - a file header that lists the current revision number on the trunk, any
tags on the file with the corresponding revision numbers, and some
additional fields like access, lock, comment, etc.  For example:

head    1.31;
access;
symbols
        before-content-200510-merge2:1.30.22.8
        content-200510-merge2:1.30.22.4.34.1
        content_merge_20051007:1.30.22.4.34.1
locks; strict;
comment @# @;

 -  after this header is a section with a list of revision numbers, date and
time the revision was created, the author, and branches the revision's on
and a pointer to the prior revision.  Eg.

1.31
date    2002.08.26.19.25.27;    author jim;     state Exp;
branches;
next    1.30;

1.30
date    2001.10.31.17.42.42;    author damian;  state Exp;
branches
        1.30.10.1
        1.30.22.1;
next    1.29;

1.29
date    2001.10.31.17.08.35;    author sal;     state Exp;
branches;
next    1.28;

 - after the list of revision information is a set of diffs plus comments.
IIRC, the first revision listed will contain the entire contents of the file
from the version on the trunk, while the following entries are all diffs.
For example:

1.31
log
@changed CurrentCustomer to Customer
@
text
@<IMPORTBEAN BEAN="/lci/dashboard/DashboardSearchUtility">
<importbean bean="/lci/userprofile/Customer">

<DROPLET BEAN="/atg/dynamo/droplet/Switch">
  <PARAM NAME="value" VALUE="bean:Customer.subClass">

[snip]

</DROPLET>
@

1.30
log
@breadcrumb clear command
@
text
@a2 6
<!-- clear value -->
<droplet bean="/lci/droplet/BreadCrumbs">
   <param name="level" value="1">
   <param name="display" value="">
</droplet>
<setvalue bean="/lci/droplet/BreadCrumbs.clearBreadCrumbList" value="clear">
@

When you checkout a specific revision, I believe CVS grabs the version from
the trunk and then uses the information at the beginning of the ,v file to
determine the order in which to apply diffs to generate the revision you
requested.

-Damian

> -----Original Message-----
> From: dave [mailto:address@hidden 
> Sent: Friday, October 21, 2005 11:10 AM
> To: address@hidden
> Subject: Code-wise, How Does CVS Do Versioning?
> 
> 
> This is more or less a question about the workings of the CVS 
> archive. I am assuming a tag/label is a set of file pointers. 
>  So, when you ask for all the files withing a certain 
> tag/label, it just traverses these pointers.  If this is not 
> how CVS works internally, please correct me and inform me how 
> it uses the tag/label meta-data to reconstruct a view from a 
> label/tag.  But, my question is still assuming the file 
> pointer scenario.
> 
> Suppose you have a file f with versions f_0, f_1, f_2, . . . 
> , f_n. Where f_0 was the first version of the file and f_n is 
> the current version.  There are two naive ways of doing archiving:
> 
> 1) Strict archive.  At time t=n+1, the archive contains f_0, 
> f_1, f_2, . . . , f_n and the current version is f_(n+1).  
> i.e. the archive is strictly an archive and only contains the 
> older versions.
> 
> 2) Current archive.  At time t=n+1, the archive contains f_0, 
> f_1, . . . , f_n, f_(n+1).  i.e. the archive contains every 
> version of the file including the current version.
> 
> But, why would you include a copy of the current version?  
> Good question, my dear reader.
> 
> Consider when a tag/label is made on the current version of 
> the file. Case 2 is easy.  It will simply point to the file 
> f_(n+1) in the archive which will (hopefully) never change.  
> However, in case 1, the tag will point to f_(n+1) which is 
> the working copy.  If the user changes this, then f_(n+1) 
> will move to the archive.  This file, in turn, must get each 
> label it is associated with and tell that label/tag to point 
> to the file f_(n+1) in the archive.
> 
> Of course, it could always do a hybrid (i.e. do case 1, but 
> if tagging a current version, copy to archive, point to 
> archive).  However, the provided hybrid would have to know 
> not to duplicate the current version in the archive (i.e. f_n 
> is working version, it is tagged and copied to archive 
> version f_n, then working copy f_n is modified to f_(n+1) but 
> f_n should not be copied to archive).
> 
> So, if you have read through this all and understand it all, 
> please provide your comments whether they be CVS based or 
> personal opinions. I am working on a system which needs to do 
> versioning and assume the CVS community has thought much 
> longer on this problem than I.
> 
> dave
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden http://lists.nongnu.org/mailman/listinfo/info-cvs
>