Re: Feature request/ideas

[Frank Hemer]

Hi Derek,

> Mark D. Baushke wrote:
> | Frank Hemer <frank@hemer.org> 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