> 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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
