[BUG] bogus name_version in bzr.newformat

[John A Meinel]

John A Meinel wrote:
> Robert Collins wrote:
>
>>On Mon, 2005-10-03 at 15:56 -0500, John A Meinel wrote:
>>
>>
>>>After upgrading the bzr.newformat tree into the new format, I was
>>>playing around with it, and I noticed that it seems to be updating the
>>>"name_version" field even if the name did not change.
>>>
>>>I realize, we may be getting rid of this field, and changing it to
>>>"revision" for just the last changed version.
>>>
>>>The specific file I noticed was "adoption.txt". As near as I can tell,
>>>the actual name doesn't change, and neither does the parent (perhaps the
>>>parent of the parent changes???) The text_sha1 doesn't ever change, and
>>>the text_version seems to agree.
>>>
>>>So why would the name_version be changing?
>>
>>
>>It should change if the parent or the name changes. Anyway, that field
>>is nukified in my format-5 tree - could you see if it happens there ?
>>
>>Rob
>>
>
>
> Well, it still seems to happen.
> The simple way of detecting, it to just do:
>
> grep revfile.txt .bzr/inventory.weave | vim - -c "set nowrap"
>
> And notice that you see "revision=" change, without text_sha1 or any
> other changes.
>

...

>
> Now, maybe they were moved around here and there, but 60x seems too much.

The one thing I thought about is the statement:
    On regular commits without merges, files that are unchanged retain
    the same text_version they had in the basis version, and files whose
    text is changed get a text_version equal to the new revision id. For
    merges, files that had different versions in any of the parent trees
    have their text version updated, even if the text is the same in all
    of them.

So some of this might be because of a merge. But why is the revision
number for the "bzrlib" directory changing? As far as I know, it was
only changed one time. Does that mean from then on, because somewhere in
the ancestry (not the diverged ancestry, the common ancestry) it
changed, now it always gets a new revision id.

That is my guess. That the code which says "if this has changed in the
ancestry, give it a new revision id", doesn't track the fact that the
change occurred in the common portion of the ancestry.

Which make me think we need to update it. It should be more thorough
saying that "if the revision id for an entry is the same in both
branches, then it should not be updated". I think that gives us the
behaviour that we want.

John
=:->


>
> John
> =:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051004/a882415e/attachment.pgp