[MERGE] Clean up pull -v

[Martin Pool]

On 16 Dec 2008, Aaron Bentley <aaron at aaronbentley.com> wrote:
> > I said: please, stop adding public functions in bzrlib.log, there
> > are already too many there, even some evil ones that nobody
> > should use (find_touching_revisions for example).
> 
> I don't understand why log is any different from branch.py or
> repository.py in that respect.
> 
> > I plan a
> > deprecation dance there which will already be painful, have
> > mercy, please.
> 
> I don't understand why introducing good APIs would hinder deprecating
> bad ones.

Thankyou for reviewing it Vincent.  I'd have to agree with Aaron here:
there certainly is cruft in log.py and cleaning it up would be very
good, but that's not a good reason not to add new functions there.  Some
of these things have a feeling of tying extra work on to patches to make
ourselves do it, but it's not really rational.  

It's better to let this patch in and then post one which e.g. deprecates
the ones you dislike, or if we're not ready to technically deprecate
them adds comments or docstrings.

I'm also skeptical about marking interfaces private just because they're
new, or just because they may change in future.  With the toolkit we
have in Python this just doesn't work well.  Make them private if
they're just to do with an implementation and no caller would want to
know about them.

So I wonder when does it make sense to give negative feedback on adding
new public interfaces?  I think in these cases: when they're
inconsistent or redundant with an existing interface, or nearly so, and
they should be harmonized, or when a caller would have no desire to know
about them.  Maybe some other cases.

-- 
Martin