-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Frank Hemer wrote:
| 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?
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.
|> | 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.
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.
Regards,
Derek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCJolFLD1OTBfyMaQRAh9PAKDgLls52frl/SMVxSmD9ntd6LPXpACfc44B pfkbw4qcnV+aP6sM4PlBy3g= =Esmc -----END PGP SIGNATURE-----
_______________________________________________ Bug-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-cvs
