> I agree this is a bug, but external tools should not be parsing the
> command output to synchronise with bzr, because a use could trivially do
> any operation without using your tool and thus desynchronise things.
There might be better solutions in theory, but in my world, it's
a pretty good simple solution, whose limitations don't surprise users:
it's OK if doing something behind the tool's back leads to the tool
giving out out-of-date information, especially if the tool actually
checks his assumptions whenever it needs them.
> We have a growing library of robust machine processable apis in the
> xmloutput plugin, which will be getting moved into the core.
Plain text is much easier to parse than XML i the Emacs world, but an
XML format might be just fine.
This said, the format is not what's at stake: the issue is about making
sure that every command outputs (or can be made to output) the list of
changes it performed.
> I agree this is a bug, but external tools should not be parsing the
> command output to synchronise with bzr, because a use could trivially do
> any operation without using your tool and thus desynchronise things.
There might be better solutions in theory, but in my world, it's
a pretty good simple solution, whose limitations don't surprise users:
it's OK if doing something behind the tool's back leads to the tool
giving out out-of-date information, especially if the tool actually
checks his assumptions whenever it needs them.
> We have a growing library of robust machine processable apis in the
> xmloutput plugin, which will be getting moved into the core.
Plain text is much easier to parse than XML i the Emacs world, but an
XML format might be just fine.
This said, the format is not what's at stake: the issue is about making
sure that every command outputs (or can be made to output) the list of
changes it performed.
Stefan