[MERGE] Output refactoring and XML integration into bzrlib
Guillermo Gonzalez
guillo.gonzo at gmail.com
Fri Nov 23 04:06:49 GMT 2007
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.
More information about the bazaar
mailing list