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.
On Tue, 15 Apr 2003 09:21:02 -0500, "Kari Hoijarvi" <hoijarvi at me.wustl.edu> wrote: >Another is to change the code that writes this output >and make it to emit XML. I cannot see, how this could >be more difficult that the first option. It requires >changes to the code, but on the other hand, every change >would first test if the flag -xml_output is in place, >so the chances of introducing bugs would be small. Firstly it isn't in one place. There is no place in CVS that can be called an 'output', it's just random print statements during the execution of the code.... 99% of it is desgned to be human-readable. Secondly it's all server side - your client would not work with any other CVS servers, making it useless to most people (cvsnt servers are very much in the minority). If someone wanted to write an XML client that would talk the client/server protocol and convert it then that might work, but it's a big job - the sheer number of different outputs that CVS can create means it'd take a while just to work out a proper schema let alone code it. >CVS output is easy to parse. If XML was just a file >format, I would not be so keen on it. But it's the schema >that I'm currently taking advantage of. Besides validation, >I use them for SQL-XML mapping and especially user >interface generation. Been there...I don't envy you the task... You'll find that to get any worthwhile speed (without quad Xeons doing the processing) you'll have to write custom parsers for each block of XML. 8 programmers worked on that stuff for 3 months here and the result still runs at 40% of the speed of the non-XML version (but 'marketing' like it, so we're stuck with it). Tony