Re: Feature request/ideas

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Price <derek@ximbiot.com> 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-----