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.
-----Original Message----- From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf Of Tony Hoyle After taking a look, I have to agree: if someone wants to get XML output, it's better to translate the CVS output to XML. >>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. Taking a quick look to two commands, diff has around 50 printf statements. It indeed isn't modular, formatting is mixed with the content. Update looks much better, it has functions like history_write and write_letter, separating formatting, but still it won't be easy. >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). This might be THE reason to implement it on the client side by parsing any server text output. Accepting dependency to COM or python is a smaller limitation than requiring the server to be CVSNT. >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. I do believe it's a big job, CVS after all is a big system. Anyway, if someone wants to script CVS now, it's difficult: I use four commands: update, add, diff and commit, and just a few flags with them, still it took me a while to get the python script right to cover enough responses. >>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). I'm not interested in speed or massive amounts of data: my main focus is scripting routine commands and metaprogramming with xml schema. Generating views and forms is fast enough if you don't have big amounts of data, and if you do have 15000 items on your form, you'll probably have more serious usability issues to solve than plain speed. Kari