-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

| 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.

Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJfyTLD1OTBfyMaQRAp4VAJwIcxGtZdBygmVoNANNl+XuG0FYqQCg+Ag8
Hq6ll1ifDJY5XRmQs72d4nE=
=7KtA
-----END PGP SIGNATURE-----




_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs

Reply via email to