-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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)? 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. 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. I am also wondering how the datestamp version can generally interact with the new .prev and .next tags... -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCL1es3x41pRYZE/gRAiw+AKCeiMkGxMU6v2jxylYTs3J3oPVoiQCgkPQE MqK3n39/wztXp4QK4Dp6gKw= =PQk4 -----END PGP SIGNATURE----- _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs