Re: Feature request/ideas

[Frank Hemer]

> Glancing at your doc and test cases, I gather that this change just
> tags the revisions and does not yet provide a way to get at the
> information for diffs/merges/etc.?

That's right. I didn't like the way cvsnt evaluates tages - or better - the 
commitid tags. Because this is related to the general enhancement of tags 
(.previous and alike), I'm looking forward to your suggested shot at 
implementing Steve Cameron's idea/patch. Maybe (probably?) this will allow a 
better approach?

However, the current patch allows log and status output to be parsed for the 
commitid on the client side - to identify related revisions.

Btw: The cvsnt uses commitid tags in the following manner:

@commitid: the specific commit
@<commitid: the previous commit

The id is evaluated in rcs.c::translate_symtag(), adding just a few lines 
would add this all, but imho that solution is not the best.

It's a matter of compatibility: If we want to stay compatible with cvsnt, we 
have to follow the same policy ...
My personal preference would at least be to use sth. more clear like 'id:' to 
identify a symbolic tag as a commitid, instead of the '@' char. But most 
likely that's not worth breaking compatibility ... maybe allow both???

What do others think about this?

Regards
Frank