Hi Larry, But the problem of missing tags should only come up when a file initially doesn't exist, and then does. The reverse cannot happen because the dead revision should still be tagged, shouldn't it(?) if the file is removed via cvs rm. The only exception would be a faulty tagging process where the file wasn't tagged with others. In that case I would say it's a faulty behaviour coming from incorrect use. The alternative of faulty behaviour from correct use is more serious.
The branching problem you mentioned doesn't come up for the coming up into existence problem, because every file always starts from 1.1. Said another way, every file has a single beginning, but multiple possible ends. In this case, my suggestion of selecting every revision up to the end tag makes sense, doesn't it? People's thoughts? -- Matthew -----Original Message----- From: Larry Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 December 2003 7:48 AM To: Matthew Herrmann Cc: CVS Mailing List Subject: Re: cvs rlog -rTAG1::TAG2 doesn't handle newly added files Matthew Herrmann writes: > > I upgraded to 1.11.9 but this didn't solve the problem. Sorry, I knew there were a number of fixes to that code and I was hoping that they would fix the problem. Now that I think about it a bit more, however, I don't think it's fixable. I don't think there's any way for CVS to intuit, in the general case, what a missing tag should mean. For example, if it's the end tag that is missing and there's more than one branch past the start tag, which branch should CVS follow? -Larry Jones Oh, now don't YOU start on me. -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
