[RFC] PushResult.report is in the wrong place?

Robert Collins robertc at robertcollins.net
Tue May 22 18:19:59 BST 2007


I think that PushResult objects are good - they encapsulate the state
built up during the push, but that report is a UI layer function, not a
core library function. Specifically its no use for GUI's (you end up
reporting to stringio and then showing that (blech) or not using report
at all (and missing out on tag stuff), and when you have custom Branch
classes the tag reporting stuff interacts somewhat too.

One axis here is the Branch class: what the branch has that can be
altered during a push/pull. We're kindof showing a difference between
branches here.
Another axis is the output style wanted - GUI, minimal CLI, detailed
CLI.

I'd like to see the Result object really focus on gathering the
information ready to be reported, with no logic that is UI appropriate,
and provide some other object to encapsulate deciding what should be
reported in a given UI and how. e.g. PushResult can answer 'how many
bytes were transferred' and 'number of merged revisions' and 'date of
the tip before the push'.

So specifically, I propose that the UI logic go back to builtins, or
perhaps to a ResultReporter class.

Also, if this makes sense I'd like us to add a 'red flag' during reviews
for anything that contains presentation logic in
branch/workingtree/repository or related modules.

Any thoughts?

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070523/c70ebcac/attachment.pgp 


More information about the bazaar mailing list