At 08:18 PM 1/21/2002, you wrote:
>Withers, Robert <rwithers at quallaby.com> said:
> >> "cvs upd -r TESTED" would do the job of grabbing the "TESTED" release.
> >
> >Yes, but only if you have a single TESTED version.  I suppose you could
> >retag the trunk as each version was released.  This was why I mentioned the
> >history command, so one could get a list of available tags to load, per
> >module.
> >
>The easiest way is to use the '-f' option on 'cvs tag' - this will move
>existing tags, so there would indeed be only one TESTED version.

Excellent, Cees.  That would certainly do it.

> >Ok, let me see ...  got one.  How could we query the available tag/module
> >combinations before we checkout?  :)
> >
>Not easy to do with CVS. With Trug, I tricked a bit by having a hidden file
>and making sure it was modified before every CVS command; in this way, there
>would be one file with a complete revision log I could query.

That's an interesting approach.  It lived on the server, of course.  How 
did you hide it?  If I may ask you several other questions about 
this...Could you explain where that file lives/is named?  Did you setup a 
commit rule to add this log message to the file, from the server?  How 
would you get the file or query the file?


>BTW, given Subversion (see elsewhere), we might not want to invest too much
>time in CVS wizardry. Seen there, been it, ate the t-shirt.

Yes, but I would have to say that now is probably not the best time to go 
changing it again.  It's not my call, of course, but considerable time has 
been spent getting the VM into CVS.   Things are very close to really 
coming together and I think that should be finished, first.  In using it, 
over time, it may become clear that Subversion or even Glorp + MySQL would 
be of benefit to move over too.

Rob