Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
The input to the tool is the list of Task labels and the previous build label. That should be enough for the tool to figure out what to promote. Now I can write a script/gui/whatever that runs cvs rlog to get all the revision information for all the files parses it builds a database out of the information figures out what gets labeled with the new build label, issues label commands for each file individually and checks out the build, in fact somebody did that with our last CM system and it was a nightmare we're talking hours to generate and checkout a build. I'd like to work to CVSNT's strengths to avoid a repeat of this. It seems that enough people have worked on and used cvs that these problems have been solved before and there is a proper way to use the tool to accomplish what I need. Personally I think that using branching for each task very closly matches what I want except for a few annoyances (see my earlier post in response to Glen) Matt S. "Merrill Cornish" <merrill.cornish at earthlink.net> wrote in message news:mailman.53.1114198289.20198.cvsnt at cvsnt.org... > Matt, > > >>> It seems like there ought to be a way to have the tool do most of the > >>> work for you. > > How much a tool can do for you depends a lot on how you decide what to promote. If one person is responsible for the promote decision, then that person's got to specify the promotion choices. Perhaps you can create a click-to-promote GUI. Perhaps the person creates a list of files and revisions that a script reads. In either case, you can't talk about what a tool does without deciding what the original input to the tool is. > > Merrill