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