Re: Feature request/ideas

[Derek Price]

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

Frank Hemer wrote:

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


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