Re: Feature request/ideas

[Frank Hemer]

On Wednesday 09 March 2005 21:08, Mark D. Baushke wrote:
> 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)?

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