[RFC] Update should mention WHAT it is up to date with

Maritza Mendez martitzam at gmail.com
Thu Dec 10 04:09:43 GMT 2009

+1 ...anything which makes it clear what software is doing...without
impairing function...is a good thing.  I know some people may say RTFM
but I say these are opportunities to reinforce what Is written in TFM.

On 12/9/09, Neil Martinsen-Burrell <nmb at wartburg.edu> wrote:
> There have been a sequence of bugs arising from the fact that ``bzr
> update`` is a legitimate command in a branch with its own working tree,
> but often it doesn't do what users want.  What people often want is to
> get their branch "up to date" with some other branch and they should be
> using ``bzr pull`` or ``bzr merge`` to do so.  I run into the situation
> when using bound branches that I often unbind for offline commits.
> Then, when unbound, ``bzr up`` is a successful no-op, but what I *meant*
> is to make this branch up to date with the branch it was bound to.
> I've wanted for a while to address this by using the message: "Up to
> date at revision x of branch y" and I have a branch of bzr that does
> that, but it causes lots of test failures (understandably) and before I
> go fixing all of them, I wanted to hear some feedback.
> Do people feel that this will address the issue with update being not
> what people want, by informing them that their working tree is up to
> date with its (local) branch?  Is it otherwise useful (e.g. for those
> using switch a lot)?
> Implementation questions:
> Is there a bzrlib function to take a branch.base URL and shorten it (for
> example, file:/// URLs could have the URL prefix removed)?  Should we
> try to use "." in the shortened form if possible?
> For tests that have very long and varying branch names, should I just
> change assertEndsWith("Up to date at revision 1\n") to an appropriate
> assertContainsRe?
> -Neil

More information about the bazaar mailing list