Hi Derek, > Mark D. Baushke wrote: > | Frank Hemer <[EMAIL PROTECTED]> writes: > |> However I didn't have a better idea. Using .base instead can be > | > | similar > | > |> miss-interpreted since there is BASE. How about replacing '.root' > |> with '.tail', and replacing '.origin' with '.root'? > | > | Hmmm... I like replacing '.origin' with '.root' and I agree that > | .base is too confusing with BASE. I have a mild dislike of '.tail' > | even though it does have some symmetry with HEAD... (I keep > | thinking that 'tail file' gives me the latest bits appended to the > | file.) > > Actually, I was waiting for Frank to finish his patch, but, when he > was done, I was going to insert .base as a synonym for BASE, and .head > as "the head of the current (possibly sticky) branch", and deprecate > HEAD and BASE to clear the namespace. Then .trunk.head would be a > synonym for the old HEAD, BRANCH.head could be used to explicitly > specify the head of any branch, and .head would refer to the head of > the sticky branch in the current workspace.
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? > | If you don't like '.first' (mentioned in a previous e-mail), > | perhaps '.branch' is a another alternative name that could be used > | as the first revision on the branch? > > Actually, the revision specified by .tail is meaningless to CVS, as > Larry pointed out. It had occurred to me that it was pretty > meaningless earlier, but on further consideration, it is totally > meaningless or worse than meaningless (in being potentially > misleading) once it is applied to multiple files. There is no reason > to expect that the *.1 branch revision of one file was committed even > close to the same time as the *.1 revision of a second file, so such a > specification across multiple files could only confuse a user > expecting it to mean something. 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. Regards, Frank -- - The LinCVS Team - http://www.lincvs.com _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
