Ming Kin Lai wrote: > > This is to continue the discussion of the thread with the same subject that > started on Dec 7, 2004. > The original discussion appeared to focus on the expansion of the $Log$ > keyword both in the file and as output by the "cvs annotate" command (under > version 1.11.17); but I think other keywords such as $Id$ have the same > problem. I am running CVS version 1.11.6 on Solaris. After I committed a > file that contains some keywords, (I did not perform a checkout or update > after that,) the file in my working directory shows the following:
See my reply to your 'Inaccurate documentation re "cvs tag"'. commit does an update to keep things consistent between your sandbox and the repo when it gets done. BTW I think you should stop thinking of ci and co, which are RCS commands, and start thinking in terms of checkin and checkout which are CVS commands, and imply a bit more work. (although CVS will happily let you abbreviate checkin with ci and checkout with co, do not try to abbreviate the concepts.) <SNIP> > Annotations for compiler.c > *************** > 1.3 (mingl 12-Jul-05): $Id: compiler.c,v 1.2 2005/07/12 02:32:17 > mingl Exp $ > 1.3 (mingl 12-Jul-05): this is $Date: 2005/07/12 02:32:17 $ > 1.2 (mingl 12-Jul-05): $Log: compiler.c,v $ <SNIP> > >From the leftmost column, it is obvious that the latest revision is 1.3; > however, the keywords expand to only revision 1.2. > > 1. Todd Denniston states that "If I Recall Correctly, $Log:$ is expanded on > checkout, so the last > (chronological) log entry seen in a Log in a sandbox has not yet been > checked into CVS. Therefore, the repository knows nothing about it, and can > not annotate what to it does not exist." (Larry Jones says similar thing: > "the $Log$ keyword (not command) is expanded > by checkout/update".) > I think the first half of the sentence is inaccurate: > apparently the keywords are expanded (in the working file) upon commitment > (check-in), i.e. no subsequent checkout is needed. No you misinterpret the situation, because commit syncs your sandbox with the repository after it does the commit. > (What Todd probably > meant is: $Log$ is expanded in the ,v file on checkout. - But see my Points > 2 and 3 below.) And I think "check in" and "check out" should not be > confused. ci and co are two separate commands, aren't they? Yes and NO. co can be performed separate, but in a Concurrent situation, a ci must be followed with a co to have your sandbox in sync, CVS handles it for you. (some where around here I expect Larry, Derek or Greg to hit me with a clue stick.) > The keywords > are expanded in the working file on checkin, not checkout. In fact, Section > 12 of the cederqvist 1.11.20 manual states " Embedded strings of the form > $keyword$ ... in a file are replaced ... whenever you obtain a new revision > of the file." The way I interpret the phase "whenever you obtain a new > revision of the file" is "in a working file that has a new revision number". > So, when you commit, you obtain a new revision. You don't need to check > out to obtain a new revision. correct you obtain the new revision because commit updates your local directory to re-expand the RCS keywords. > Now, what "annotate" shows is another > question. Section A.7.1 of cederqvist says "[annotate] print[s] the head > revision of the trunk, together with information on the last modification > for each line". I will discuss that in Point 4. > <SNIP> > 3. Todd says "the log entry not yet been checked into CVS". I think that is > the implementation detail that users should not be concerned with. From > users' perspective, all cederqvist in effect says is "After a local file > with a keyword is checked in, the keyword in that file is expanded to > reflect the new revision information." Maybe Todd knows that the keyword is > actually not expanded in the ,v file at the time of the check-in so the ,v > file does not have the keyword expanded to reflect the new revision > information. But I am hesistant to use some undocumented implementation > details, rather than cederqvist, to explain the program behavior. Actually, it is a known thing that the RCS keywords cause problems / misunderstandings and it is expected that if you really want to use them you will do enough reading and experimenting to understand their intricate problems in a concurrent environment, i.e., they were made to be used in RCS not CVS and their behavior because of the RCS history makes them act kind of badly under CVS. > > 4. cederqvist says annotate should print the last modification on each line > (Sec A.7.1). > It does not say whether the modification is in respect to the > local file or the ,v file. partially agreed, the manual does indicate that it is printing "the head revision of the trunk" which implies the version from the repository. I am not certain (someone needs to test) if you are on a branch if annotate does the branch instead of the trunk. assuming annotate will show branch information if you are on a branch instead of the trunk, the manual should say: "For each file in files, print the head revision of the trunk (or if you happen to be on a branch the head revision of the branch), together with information on the last committed modification for each line." > Neither does it say what "modification" means in > respect to keyword. The user does not really "modify" the line that has the > keyword. Actually as I tried to let you know the last time we had this discussion, from CVS's perspective the user does modify the RCS keyword lines. The lines are not stored in the repository until the user does a commit. > It is the CVS system that "modifies" it by expanding the keyword. > And apparently the local file is "modified" (in the sense the new revision > information is reflected) as the user sees it. On the other hand, the ,v > file is not "modified" (but because cederqvist is silent on that, it can be > changed in future release). Nevertheless, cederqvist is talking about each > line in the "source file" (i.e. the local file) not the ,v file CVS rightly takes the perspective that it knows nothing about the local file, which might even not exist at this time, you are incorrect. <SNIP> > 5. Larry Jones says "the $Log$ keyword (not command) is expanded by > checkout/update". > For the record, the annotate output is not affected by update: It is expanded, not committed. <SNIP> -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
