[BUG][0.12] 'bzr init' creates branches incompatibile with bzr-0.11

[John Arbash Meinel]

Martin Pool wrote:
> On 17 Oct 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> Because of this bug in bzr-0.11, it seems we need to only create trees
>> with unique roots after we bump the disk formats for working tree and
>> repository. We already have RepositoryKnit2 almost ready to go, we just
>> need to update WorkingTree as well (WorkingTree4, in essence, just
>> changes the .bzr/checkout/inventory to be a format=6 inventory).
> 
> Just to digress a little on the general approach to formats: the general
> rule is that we should only write into a version X object the same data
> that would have been written by previous releases that also handled
> version X.  Otherwise it's just too hard to be sure that things we've
> written out can actually be read back safely, without getting into
> fairly complicated testing of data between different versions.

Right. There is a little bit of leeway allowed in the case that the old
version might have been writing the wrong thing. But yes, that is the
preferred route. As another example, the current XML serializer still
writes unicode characters using their XML escape sequence, rather than
using a UTF8 string, because bzr-0.8 had a bug if we created real UTF8
(it tried to decode it twice, which only worked with plain ASCII XML).

It actually turns out that the cost is minor, and in my testing it was
actually faster to do it that way then to deal with going through utf-8.
So the specific cost of us doing that is small. But the motivation
behind it was to avoid arbitrarily breaking compatibility with old
released versions.

> 
> (It might be good to test that systematically - do a blackbox test that
> makes a branch with version 0.12 and then tries to check it out with
> every previous version.  But even then we will probably not get so much
> coverage of the data format as we do with our current approach.)
> 
>> I think it is a little late to do this sort of format bump for bzr-0.12,
>> so I'm proposing this simple fix:

...

> +1 from me, though I would really like to get input from Aaron since
> this is his area.  However, I do take your point that people can create
> difficult repositories this way so if you want to fix it first and talk
> about it later it's ok with me.

Agreed. I'd like to defer to whatever fix Aaron would like. I only
merged the quick fix because it means people who are testing bzr.dev
won't create branches that are then not supported by earlier versions of
bzr. I'm actually happy to have bzr.dev support trees with unique roots
in 0.12, which is why I would rather not revert all of the changes. And
just have it more as avoiding creating data that isn't compatible.

> 
> As you say, given that 0.11 cannot accomodate a root id here, we will
> need a new workingtree and repository format to bring this in.  It's
> your call as RM whether this can be done for 0.12.  Since we're before
> RC and it would hopefully be a small change it might be OK.  But on the
> other hand perhaps it should be combined with any other format changes
> we want for 0.13.

Well, I'll also be traveling for one day this week. But if someone went
ahead and implemented a WorkingTreeFormat4 including the upgrade code, I
would consider it for merge into bzr-0.12. Especially if it was not set
as the default format. I don't know that we want to be strict about it,
but it could be nice to have support for a format one release before it
becomes the default format.

Attached is the patch that I actually submitted to the pqm. I'm happy to
refine things further if Aaron has any suggestions. I just wanted to get
a stop-gap in place so that people can test what should become bzr-0.12.

John
=:->

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: no-unique-roots.diff
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20061017/65392b5d/attachment.diff