Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Matthew Herrmann writes: > > just to clarify, it should include TAG2 only in the case where a tag does > not exist for TAG1... Right. If TAG1 and TAG2 are both attached to the same revision, the revision specified by TAG2 would not be *after* the revision specified by TAG1 and thus would not be included. -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
just to clarify, it should include TAG2 only in the case where a tag does not exist for TAG1... -Original Message- From: Larry Jones [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 9 January 2002 05:00 To: Matthew Herrmann Cc: [EMAIL PROTECTED] Subject: Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r Matthew Herrmann writes: > > since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what > people would expect it to do. Would anyone object to changing it so that it does revisions after TAG1 and not after TAG2 rather than after TAG1 and before TAG2 (e.g., currently it is exclusive of both TAG1 and TAG2, the change would be to make it inclusive for just TAG2)? -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
[ On Tuesday, January 8, 2002 at 13:00:19 (-0500), Larry Jones wrote: ] > Subject: Re: request for log option to specifically exclude the first tag, >workaround for cvs log -r -r > > Matthew Herrmann writes: > > > > since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what > > people would expect it to do. > > Would anyone object to changing it so that it does revisions after TAG1 > and not after TAG2 rather than after TAG1 and before TAG2 (e.g., > currently it is exclusive of both TAG1 and TAG2, the change would be to > make it inclusive for just TAG2)? That sounds much more logical. The goal is to produce a change log for a "release". The changes to be described are only those those after TAG1, up to, and including, any for TAG2, iff TAG2 is on a different revision from(after) TAG1. I.e. do not print the log entry for TAG2 if it's on the same revision as TAG1. The analogy is with the "cvs diff/patch/rdiff" commands where deltas are only displayed if there is a difference to be displayed. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Matthew Herrmann writes: > > since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what > people would expect it to do. Would anyone object to changing it so that it does revisions after TAG1 and not after TAG2 rather than after TAG1 and before TAG2 (e.g., currently it is exclusive of both TAG1 and TAG2, the change would be to make it inclusive for just TAG2)? -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Have you looked at rinfo? It does what you ask, for a single RCS file. You'd have wrap it in a script that traverses your repository to see all changes in your project. You could also combine it with lmerge to produce more concise reports. Both of these programs are available at http://www.wakawaka.com/source.html --- Forwarded mail from [EMAIL PROTECTED] I think this topic has not been given enough discussion, namely the problem that it is *impossible* through using standard CVS commands to get the log messages _taking_ one from a tag to another tag. This thread got dropped a while ago by people quietly whispering "oh well, it can't be done" and others saying "well it does work, read the newsgroup" without trying it. All of the log -rR1::R2 -rR2 etc. style methods all fail in at least some cases, especially when there has been no change to a file over two tags, so a revision number is tagged with both tags (try it!) I think if anything, this is a feature which deserves to be added to the new dev version, as opposed to emacs support or what have you... I was amazed it hasn't been come across before. Anyway, enough rant, I think I may have found a pragmatic workaround that recent discussions about dates inspired me on: find the dates of the two logs, and then do a cvs log from just after the last committed date/time of the first tag, and up to and including the date/time of the last file containing the second tag. But that won't be sufficient if you're using branching -- you'll then need to ensure that you're only getting log messages from the branch containing both tags. I haven't implemented it yet, but ... agh! i think this would be how it works (not tested): run perl/python script to get dates of both tags find maxs/mins and feed these into: cvs log -d"DATE1TAG2 since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
request for log option to specifically exclude the first tag, workaround for cvs log -r -r
Hi all, I think this topic has not been given enough discussion, namely the problem that it is *impossible* through using standard CVS commands to get the log messages _taking_ one from a tag to another tag. This thread got dropped a while ago by people quietly whispering "oh well, it can't be done" and others saying "well it does work, read the newsgroup" without trying it. All of the log -rR1::R2 -rR2 etc. style methods all fail in at least some cases, especially when there has been no change to a file over two tags, so a revision number is tagged with both tags (try it!) I think if anything, this is a feature which deserves to be added to the new dev version, as opposed to emacs support or what have you... I was amazed it hasn't been come across before. Anyway, enough rant, I think I may have found a pragmatic workaround that recent discussions about dates inspired me on: find the dates of the two logs, and then do a cvs log from just after the last committed date/time of the first tag, and up to and including the date/time of the last file containing the second tag. But that won't be sufficient if you're using branching -- you'll then need to ensure that you're only getting log messages from the branch containing both tags. I haven't implemented it yet, but ... agh! i think this would be how it works (not tested): run perl/python script to get dates of both tags find maxs/mins and feed these into: cvs log -d"DATE1TAG2 since it would be used pretty commonly -- shame -rTAG1::TAG2 doesn't do what people would expect it to do. Regards, Matthew Herrmann -- Far Edge Technology Level 11, 80 Mount St North Sydney NSW 2060 Australia Ph: 02 9955 3640 Mob: 0404 852 537 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
