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 _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs