[BUG] spurious tree root changes in workingtree2 and 3

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:

The behavior you describe is intentional.

Formats that don't support unique roots also don't treat the tree root
as a proper directory.  knit1 doesn't store a knit for it.  Its
inventory format doesn't record roots as proper directories, so they
lack a revision attribute.

> we're generating lots of unnecessary knit records for the root.

No, we are generating no knit records for the root at all, in the knit1
format.

In knit3 repos, there is a knit for the root, and the inventory format
does record roots as proper directories.

When converting from knit1 to knit3, we need to add a revision
attribute.  We could guess at what it would have been, but this requires
scanning history, and can be confused by ghosts.  The simplest and most
reliable value to assign to the root's "revision" is actual revision-id
of the revision.  So this is what we use.

RevisionTrees (e.g. basis trees) produced by knit1 also use this value
as their "revision", to ensure that converting their repository from
knit1 to knit3 leaves this value intact.

So there are redundant records, but not in knit1 repositories, only in
knit3.

We are currently planning to change our inventory so that directories
are considered modified when their contents change.  This will mean that
all commits *will* modify the tree root (except --unchanged ones).  So
if having this many records in the knit for the tree root is a genuine
problem, it must be solved some other way anyhow.

> This fails only on workingtree2 and 3, but this may also be failing on
> dirstate when the backing repo is a non-subtrees one. I don't know if
> that is the case or not.

Right, bcause subtree repos support rich roots, not because they support
subtrees.

> It made my iterator for commit fail until I figured out it wasn't in my
> code - I can work around it in the tests if needed; but perhaps fixing
> this is the right approach.

I don't think it's broken.  I don't think fixing it makes sense.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGzYMn0F+nu1YWqI0RAoe1AJ9CK608yT0H0P4g793RmUNP7F6R3wCdHmit
gGTAEar8TcJwAgBsjZ3+Eos=
=huJa
-----END PGP SIGNATURE-----