Re: Feature request/ideas

[Frank Hemer]

> | A rational way. As a second step I would suggest to change the
> | extensions (.prev, .next, .xxx) to be allowed in head position too,
> | but I'm note sure where the sandbox tag gets processed. If
> | translate_tags() could take that into account, its not a big deal
> | ... Where is this state cached?
>
> It's cached in the CVS/Entries files in each subdir.  CVS looks it up
> in the Version_TS in vers_ts.c and decides to set it in the Vers_TS
> structure it returns only if the TAG passed to the function (via -r or
> something, somewhere) is not set.  I think it could be caught there -
> if the TAG is .XXX  (and not .trunk), then set the vers_ts->tag to
> STICKY.XXX.

Ok, thats the 'client' side. But where is it cached on the 'server' side?

> | So probably the expression used should connote this. After some
> | consideration, I would vote for '.origin' here. I disagree with
> | being meaningless. I often export a project state into a local
> | repository, work on it, and when I'm done, move the files back to
> | the remote repository's sandbox. During local development I often
> | want to compare to the initial version of a file, and using a
> | single tag for this is just easy. Granted there are other ways to
> | achieve this, but they're not as easy to handle.
>
> That's fine for 1.1, but how does this help you for a branch?  You
> might want to diff against the root, but it doesn't make much sense to
> care about the first revision on the branch.

Good point. What about resolving '.origin' to the very first revision of the 
mainline?

Regards
Frank