>> From what I understand, the problem we have is that with >>'release'-ed code, there really isn't a quick way to log into, say >>the live machine, and verify which branch was released. The only way >>to do this is to look for some changes to the code, that we know >>exist only in the latest merged branch. >> > > Look in the history file, with 'cvs history'. One thing 'cvs release' > does is put an entry there. > > You do need a higher-level process than just the cvs commands provide > to manage a full project. You can automate some of that with scripts, > or do it manually with emails or another tool.
Hmm, all we want is to have the symbolic tag of the CVS version released, to be stored in a file on the release server. This is so that deployment verification can be automated across a cluster. Have you heard of a CVS variable ( called, say, "$tag$" ? :) that holds the tag, if any, assigned to the the main branch. I was thinking of using variable replacement, but the only variables seem to be RCS ones. Sonam -- Electronic Commerce Corporate Express Australia Ltd. Phone: +61-2-9335-0725, Fax: +61-2-9335-0753 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
