On Wednesday 09 March 2005 21:08, Mark D. Baushke wrote: > Derek Price <[EMAIL PROTECTED]> writes: > > In the case where the information came out of the directory CVS/Tag > > file, it becomes available in vers->nonbranch, but not otherwise. > > > > In other cases, the RCS file gets parsed anyhow, but only on the > > server. Of course, since you need RCS information to resolve these > > tags anyhow, I expect you are currently only doing so on the server > > anyhow, whether you realized it or not. > > > > Regardless, I am reconsidering the decision to store numerical > > revision numbers for static tags. Technically, HEAD is really a > > static tag (it points to a particular set of revision numbers). It > > just happens to point to the most recent set on the trunk. Therefore, > > an update might retrieve a new head revision, but a commit will fail, > > as things stand previous to your patch. I've been assuming that .head > > would work similarly. Why not .prev and .next too? Even if only to > > simplify code, why not just leave the sticky tag just as the user > > specified it? It certainly fulfils the principle of least > > interference, where the user is allowed to shoot themselves in the > > foot if they like since they might find some use for a dynamic sticky > > someday that we didn't imagine. > > > > Of course, on the other side of this argument, I am fairly confident > > that there should not be much use for such a dynamic sticky and, > > therefore, storing a revision number when BRANCH.prev... is supplied, > > should follow the principle of least suprise, even if it might make > > status, log, etc. output slightly less legible. > > > > What do others think? > > Does -r.prev mean anything (is it another way to say -r.base.prev)?
Yes, exactly. > If so, there are some kinds of relative sticky tags that would need to > be resolved in some way if they are to be made the sticky revision. > > I have no objections to a > > cvs checkout -rcvs1-11-x-branch-last-merge.prev ccvs > > and having the sticky revision in use be updated when the > cvs1-11-x-branch-last-merge tag is moved. which is basically a good idea ... > However, I am not sure I understand how 'cvs update -r.base.prev foo' > could work as anything other than a 1.48.4.7.prev as the sticky version > for a file where the baseline version for foo was 1.48.4.7. And here you are. Because otherwise (after the update) you would have a sticky tag '.base.prev' and a revision number of 1.48.4.6. The next call to update (without any params) would again reduce the revision number by one - and that's not a good idea;-) To prevent this, my code in vers_ts.c would need to know whether the symbolic tag is a branch tag (a dynamic tag) or not, and the tag would only be reverted into a numeric tag in case it is a static tag. > I am also wondering how the datestamp version can generally interact > with the new .prev and .next tags... It can not, as it requires a dynamic tag. And there are only symbolic branch tags and '.trunk'. If a relative tag extension is used, the result is the same as if the datestamp version was used with a numeric revision: cvs diff: tag 1.3 is not in file foo Regards Frank -- - The LinCVS Team - http://www.lincvs.com _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs