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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
