[BUG] bogus name_version in bzr.newformat

[Martin Pool]

On 05/10/05, John A Meinel <john at arbash-meinel.com> wrote:
 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.

That is what it's meant to mean; that seems to imply there should be
very few revisions of the bzrlib directory.

To answer a question from earlier in the thread, it is intended that
renaming of a parent should not cause a new revision, only changing
the parent (e.g. moving between directories) or changing the name.

--
Martin