[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Major cvs surgery, need suggestions

From: Greg A. Woods
Subject: Re: Major cvs surgery, need suggestions
Date: Sat, 2 Mar 2002 14:55:34 -0500 (EST)

[ On Saturday, March 2, 2002 at 15:34:47 (GMT), David A. Desrosiers wrote: ]
> Subject: Re: Major cvs surgery, need suggestions
> >  They are merely sequential counters of revisions stored in the RCS
> > files.  If you need to remember any given point in the revision history
> > of a file, or of all the files in a module, then you really must use
> > tags and tags alone.
>       I was under the impression that the revision numbers were used
> internally by cvs itself to track the changes on a per-commit basis of
> each file? 

What do you think the "revisions stored in the RCS" files are?  The
revision numbers are simply their internal identifiers.  Tags (and
branches) need something to point to -- there's no other standard way of
implementing a high-level pointer in a text-based data structure that's
stored in a unix file.  You could use byte offsets, but they're not very
easy for humans to deal with, and they have no conceptual meaning (and
they would have to change sometimes on rewrites, particularly in the way
RCS files are structured, which would greatly increase the overhead of
RCS file manipulation).

Please read the rcsfile(5) manual page and then have a look inside a few
RCS files (preferrably some with branches and tags) and try to
understand their structure.

Now once you've done that consider that the revision numbers are only
incremented when a change, aka a "delta", is committed to a given file.
Note that when you're driving RCS with CVS you don't commit to all the
files in a module every time (usually you don't with plain RCS either of
course) -- only the changed files get new revision numbers.

>       If I go from 1.46 of a file to 1.1 in a new location, and then want to
> retrieve version 1.12 of that file, how do I do that, when all of the
> revision numbers are now missing from the new file (but of course, still
> exist in Attic/oldfile,v) 

How about the obvious:

        cvs update -p -r 1.12 oldfile > oldfile-1.12

>       ..and if I must use tags and tags alone, are you suggesting that I
> instruct my developers to tag every single file at every single commit?
> That could get tedious.

Of course not -- you only use tags (and you use tags alone) to remember
just the important revisions (project milestones, branch points, merge
markers, etc.).

You should not be trying to remember revision numbers externally from
the repository (even though they won't change like byte offsets might --
it's just that they won't behave over time in any externally predictable
way).  You should only remember tags externally.  If you really need to
dive down into the individual revisions between two tags then you need
to do that on an per-file basis and you will use "cvs log" to find out
what the specific revision numbers of interest are for a given file.

Note too that it's not unheard of for a project to "compress" all the
revisions between milestones -- this can be a great savings in space and
time for a large repository.  They just save the log entries for
hist[eo]rical purposes into a ChangeLog file or similar and then delete
the revisions between the milestone tags.  This makes all those revision
numbers "invalid", even though once again the revision numbers for the
remaining deltas will not change.  Obviously this has to be done on a
per-file basis since of course the revision numbers for given tags are
possibly different in every file.

                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]