fetching multiple tags
I found this question interesting, since I'm about to address it in a CVS wrapper I'm writing... Marc Tessier wrote: I am wandering if there is any options to extract the most recent version of a list of TAG? I have tag A, B, C and the I want to get the most recent files of all three in one cvs checkout or cvs export so I don't have to check the files version one by one. Larry replied: No. You're expected to tag all the files in a module, not just some of them. Perhaps I'm answering a different question. Here's my first solution: $ cvs checkout -r C f1 f2 f3 ... $ cvs checkout -r B f1 f2 f3 ... $ cvs checkout -r A f1 f2 f3 ... Where the first checkout gets the files with tag C. The second checkout replaces any file that has a B tag (and leaves behind any file that should be deleted as-of B I think). The third command overlays all the files tagged with A. While this approach is wasteful in that it can fetch 3 different versions of the same file, it meets your criteria for not having to think very hard to make it work right. A scripted approach, which would be more efficient is to collect the list of files and revisions first, and then get only the good ones. $ cvs -n checkout -r C-- returns the list that has tag C. $ cvs -n checkout -r B-- returns the list that has tag B. $ cvs -n checkout -r A-- returns the list that has tag A. Armed with the 3 lists, you can only fetch each file once. Though I don't have an example database handy with deleted files, so I can't say what to do about discarding them from the list. -CTH ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: fetching multiple tags
On Wed, Feb 05, 2003 at 10:14:51AM -0500, CHARLES HART, BLOOMBERG/ 499 PARK wrote: The second checkout replaces any file that has a B tag (and leaves behind any file that should be deleted as-of B I think). No; the second checkout will not leave such files behind; it'll delete them. It will do its best to leave you with *only* the files (and the revisions of those files) tagged with B. The only exceptions I can think of are: - uncommitted changes; CVS will merge them rather than clobbering them - files not in CVS at all (? status); those will be left alone A scripted approach, which would be more efficient is to collect the list of files and revisions first, and then get only the good ones. I believe that's the only approach that will work. Though I don't have an example database handy with deleted files, so I can't say what to do about discarding them from the list. Hmmm. In theory, this should probably just work -- deletion is just another revision, with a commit date. But I bet that in practice there'll be ugliness involved :-( But as Larry said to the original poster: No. You're expected to tag all the files in a module, not just some of them. Indeed. In CVS, tags are meant to label the state of the module at a given point in time, not the transitions. For the latter (and given that you've tagged the states in the first place), use cvs diff -rtag1 -rtag2. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
