[MERGE] Output refactoring and XML integration into bzrlib

[Guillermo Gonzalez]

On Jueves 22 Noviembre  2007, Aaron Bentley wrote:
> Guillermo Gonzalez wrote:
> > Hi,
> > 	As Martin say in the merge request, the patch is already splitted (as
> > Robert recommends) in refactoring and xml output.
> > 	We didn't send the xml because (we think) is trivial once the
> > refactoring is done.
>
> The bulk of your changes are related to providing an API to report on
> the differences between two trees.  But we already have an API to report
> on the differences between two trees: ChangeReporter.  And the API is
> already used in status.
>
> The only reason I can see why you'd prefer to invent your own API is so
> that you can get the human-oriented output dumped in XML form.
>
> Aaron

Aaron, 
	You are right, about we need to use _ChangeReporter, and we will. I was 
thinking that maybe a ChangeReporterRegister (like the one used for 
LogFormatter) might help to handle the multiple ChangeReporter 
implementations, please correct me if subclassing ChangeReporter is the wrong 
approach.
	There are some cases where we don't known how to use ChangeReporter, i.e: in 
status, the non-short output is generated using TreeDelta.show, also 
conflicts and pending merges output (short and standard) is generated in 
bzrlib.status.show_tree_status and bzrlib.status.show_pending_merges 
functions. Mostly for this particular case we invent our own API :).
	I'ld really appreciate some pointers about how we should implement it. I 
don't known if adding conflicts and pending merges support to  
_ChangeReporter is right. Also, should we implement the non-short output in  
_ChangeReporter?
	Our idea was to create a generic interface, so it can be extended with 
plugins.

Regards,

Guillermo.