info-cvs
[Top][All Lists]
Advanced

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

Re: Inaccurate documentation re "cvs tag"


From: Todd Denniston
Subject: Re: Inaccurate documentation re "cvs tag"
Date: Tue, 12 Jul 2005 08:34:23 -0500

Ming Kin Lai wrote:
> 
> Sec 4.5 of 1.11.20 cederqvist says: "running the cvs tag command without
> arguments causes CVS to select the revisions which are checked out in the
> current working directory.  ... One potentially aspect of the fact that cvs
> tag operates on the repository is that you are tagging the checked-in
> revisions, which may differ from locally modified files ..."
> I think it is somewhat confusing, especially to new users.  At first it
> talks about a checked-out revision, then it talks about a checked-in
> revision. Well, I understand they mean the same, at least in some cases; but
> it is not quite accurate and probably confusing.
> 1. The problem with "checked out" is that it does not literally mean
> "checked out".  

Actually it does literally mean the version which was checked out, not what
you currently have (i.e., not possible local mods).

> Suppose I check out a file with revision 1.1, modify it and
> commit it, so now I have revision 1.2 in my working directory.  

Well this commit does do essentially a checkout (actually update, which is
why things like $Log:$ and $Id:$ get updated).

> I run "cvs
> tag".  And 1.2 gets tagged.  

Because you checked out (updated to) 1.2 by committing it.

> Literally 1.1 is the revision I checked out.  I
> did not check out 1.2, unless commit implies check out - but I think it's
> better separate them; after all ci and co are two different commands.

It was learned long ago that less confusion was created by cvs handling the
immediate update, otherwise cvs would have a hard time being Concurrent
Versions System, the command you imply are serial locking commands and CVS
is a parallel merging system.

>  Also,
> stating that a checked-out version is tagged may give the wrong impression
> that the user (unnecessarily) needs to do a "cvs co" before tagging.

No the update makes it the checked out version, this is simply a
misconception on your part.

> 2. The problem with "checked in" is that there may not be any check-in (cvs
> ci).  Suppose I check out a file for the first time and without modifying
> it, run "cvs tag".  The one and only one revision gets tagged; but there is
> never any check-in.  

If you checked it out there was a check in, which created 1.1.

> Stating that a checked-in revision is tagged may give
> the wrong impression that the user (unnecessarily) needs to do a "cvs ci"
> before tagging.
> 
> Anyone agrees or disagrees?

Yes, see above.

> 
> Incidentally, the entry for tag in Appendix B (page 132) says "Add a
> symbolic tag to checked out version".  I think "checked out" need to be
> re-worded, and "version" probably should be "revision".

In most cases people tag an entire baseline (which is also the better
practice), which has a "version", but also has many files which have
"revisions". It seems clear as written from here.

> 
> Finally there are a number of places in cederqvist that use the phase
> "checked out".  I am not sure all mean literally "checked out".  For
> example, Sec 1.3.4 says "diff compare[s] the version (revision?) of driver.c
> that you checked out with your working copy."  Again, suppose I check out a
> file with revision 1.1, modify it and commit it, so now I have revision 1.2
> in my working directory.  I run "cvs diff".  There is no difference.  The
> comparison is NOT between 1.1 (the last revision I checked out (using cvs
> co))

see above information about your misunderstanding because cvs commit does an
update to get you synchronized with what is in the baseline after commit.

> and 1.2.  I think the phase "checked out" should be used with care.

It is, you simply have a little learning to do.

> 
> Ming Kin Lai
> 
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

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