Re: Feature request/ideas

[Frank Hemer]

On Wednesday 09 March 2005 15:50, Derek Price wrote:
> Frank Hemer wrote:
> | Here is a more detailed description of the tag-extensions:
>
> Mostly this sounds great, with the few questions/exceptions that I
> have noted.
>
> Could you write the final version up as a patch to doc/cvs.texinfo?

I certainly will - but I was hoping to receive some reports about ev. bugs so 
these can be fixed _before_ the patch gets applied.

Also you might have noted that I'm not a native english speaker, so this docu 
probably needs some workover ...

> | '.origin': Will always resolve to the very first revision. If a
> | file has been added on a branch, .origin will resolve to the first
> | revision on that branch, otherwise it will follow the mainline.
> |
> | '.root': Will resolv to  the predecessor of the first revision on
> | the focused branch.
>
> I think your terminology is still a little off here.  Technically, the
> root revision of a branch is on both the parent and the branch and is
> therefore also the "first" revision on the branch.  This is one of the
> reasons that I still think your ".origin" tag makes no sense.  Could
> you please either remove it or provide me with a use case that
> explains/justifies it?

Ok, in this case 'first'  has to be replaced with 'second' for '.root'. But I 
suspect there is a better word for this?

Regarding '.origin', it is the only way to target the very first version of a 
file. Using '.origin' and appending an individual number of '.next' 
extensions allows to iterate over all revisions of a file, begining at the 
initial version. The same purpose can be achieved with cvs log and taking the 
revision number - but I think '.origin' is much more handy here.

If a file has been added on a branch, and consequently does not have a '.root' 
version (usually the dead 1.1), '.origin' will return the 1.1.2.1 revision 
(if it has been called from this branch). After a merge onto the trunk, this 
behavior doesn't change. But if (then) invoked from the trunk, '.origin' will 
return 1.2 (or a higher rev. number, depending on the rev. num. it was 
committed to).

If a file has been introduced by cvs import, '.origin' called from the trunk 
resolves to 1.1.1.1.

> | '.next': The next revision on the focused branch. Does _not_ follow
> | the mainline as this would prevent access to revisions on a vendor
> | branch that were introduced _after_ the first commit/merge onto the
> | trunk.
>
> Could you please explain this in more detail?

Assuming a file has been introduced with cvs import, it will start as 1.1 and 
1.1.1.1. The next vendor import creates 1.1.1.2 and a third 1.1.1.3
At this stage, the file becomes modified and committed to 1.2.
Now two more vendor imports happen, creating 1.1.1.4 and 1.1.1.5.

Starting from 1.1.1.1 and applying several '.next' extensions allows to 
iterate over the vendor branch _without_ jumping onto the trunk.
Because of this, 1.1.1.1.next.next.next will resolve to 1.1.1.4. If it would 
follow the mainline, this would resolve to 1.2.
Non-vendor branchens however are not affected by this.

I'm not really sure whether this makes sense in all situations, but to work 
around this, '.next' would have to take the absolute tag type into account, 
blowing the code and maybe causing some sideeffects I haven't thought of yet.
The code for simply always following the mainline is still in my private rep., 
maybe this functionality can be added in a later step?

> | If a combined tag with relative extensions is used for commands
> | that change the local sandbox and set sticky tags, the resulting
> | numeric revision is used for sticky tagging. This is because tags
> | like .trunk.prev.prev imho don't really make sense - '.prev',
> | '.next' will force usage of numeric sticky tags in any position,
> | and all elative tags will if used not in head position.
>
> I agree with you here when .prev or .next are applied to a dynamic
> (branch) tag, since a request like "the tipe of the branch minus two
> revisions" seems unlikely to remain meaningful in a dynamic sense, but
> I think that applied to a static tag it would be best to leave the
> text in the sticky tag for readibility.  "release-1.0.prev" is not
> going to change unless someone moves the release-1.0 tag.

Unfortunately I don't see an easy way to achieve this. How could I determine 
whether some tag is static or not? In vers_ts.c, I only have information 
about a symbolic tag, but I don't know if this is a branch tag or a static 
tag. I could resolve the tag (requiring rcs-file access) and make the numeric 
display dependent on the result but I think this points into the wrong 
direction. Is there an easy way to find out (in vers_ts.c) what kind of tag 
has been used before?

> | If the combined tag ends with '.head', this will overwrite -
>
> Could you explain this further?

Taking a rev. num. 1.3.4.7.2.3.
Using a tag like '.root.root.' will resolve to the numeric tag 1.3. Adding 
'.head' will resolve to the head of the trunk because '.head' turns the tag 
into a dynamic tag. In this case a numeric tag would simply be erroneus.

Probably the difference between dynamic tags and relative tags should be 
mentioned:
'.prev', '.next', '.root', '.origin' '.head' and '.base' are relative tags.

Symbolic _branch_ tags and '.head' are dynamic tags.

> | I hope I have addressed all issues concerning the new tags, and
> | would very much appreciate some feedback and maybe some results
> | from testing ...:-)
>
> This all still sounds great, but it cannot be committed without docs
> and test cases.

I know, but I still I would like to get some feedback so I can provide a patch 
and use-cases that fullfill other users requiremens without having to work 
things over and over again. Actually, I was hoping some users apply the patch 
and play around a little ...

Regards
Frank
-- 
- The LinCVS Team -
http://www.lincvs.com