-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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?
| '.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?
| '.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?
| 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.
| If the combined tag ends with '.head', this will overwrite -
Could you explain this further?
| 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.
Regards,
Derek
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCLw0zLD1OTBfyMaQRAlYnAJ46v9suhl9Y576IjI5GZGcWckHyBwCeNNtj cPhg1i6KXaiOwvz6PEgZIX8= =vEFi -----END PGP SIGNATURE-----
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
