[ANN] bzr 2.5b2 released

[Jelmer Vernooij]

On 10/12/2011 12:46 AM, Ben Finney wrote:
> Vincent Ladeuil <vila+bzr at canonical.com> writes:
>
>
>> * ``bzr log`` now has an option called ``--omit-merges`` to omit
>>   those commits that merged branches, i.e. those having more than one
>>   parent.
> Hmm. This looks dangerous; a merge, like any other commit, can have
> changes of its own that don't exist in any other revision. Will this
> option ignore *only* those merges which have no additional changes?
The option isn't enabled by default, it's just there for those that want
to use it. The option will omit *all* merges. It's not possible (at
least, not trivial) to detect whether or not a merge has additional
changes - it depends on the merge algorithm used, the parameters,
possible conflict resolution, etc.
>
>> * The new experimental format ``development-colo`` supports colocated
>>   branches. This format will eventually be merged back into the ``2a``
>>   format when it has stabilized and there is adequate UI support for
>>   colocated branches.
> I'm glad to see this progress. But will the format still be “2a” after
> that change? Wouldn't it be better to have a different name, to
> differentiate the formats?
It would still be "2a" after change. The reason for this is that we
don't want to require users to upgrade before they are able to use
colocated branches. If we would make it a completely new format (with
its own name), we would have to require running "bzr upgrade" and older
versions of bzr wouldn't be able to open it.

Instead, the currently proposed colocated branch format is simply an
extension of the 2a format. Colocated branches are stored inside of the
2a directory, and older clients will simply ignore them (they also don't
have a way to address colocated branches in their UI).


>
>> * ``bzr info -v`` can now be run against branches that don't support
>>   ``last_revision_info``, in which case the branch information will simply
>>   not be displayed. (Jelmer Vernooij)
> :-( Can't the rest of the branch information be shown anyway in those
> cases?
What sort of branch information would you want to see? The last revision
date and revision number were the only things that were shown earlier,
and those both require access to the revision number and the revision graph.

Cheers,

Jelmer