Rethinking conversions to rich-root data

[John Arbash Meinel]

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


...

>> Do we *really* need to fake all of these root changes? I know there were
>> like 2 branches out there that actually had a root id for about 3
>> revisions.  Couldn't we just force that all revision roots from non-rr
>> trees are fixed, and avoid preserving this bloat for the rest of history?
> Not sure I follow this; Are you suggesting upgrading a non-rich-root
> revision to a rich-root revision should *not* mark the root entry as
> changed? This would break consistency with existing upgrades that were
> done independently.
> 
> Cheers,
> 
> Jelmer
> 

I think we could add a "bzr reconcile" that would check if the root
actually changed, and only include records for times when the root was
actually modified.

As I understand it, when you've upgraded to rich-root, then 'bzr commit'
doesn't update the last-modified for the root entry at every commit. So
why do we need it for the rest of history before the conversion?

Aaron mentioned that some of it was an attempt to handle 'ghosts'
better. But last-modified is not very compatible with ghosts anyway. We
have the same problem for file-ids that we have for the tree root's
last-modified. We can't assign the last modified to a ghost, and thus we
will end up with inconsistent data (if one person's conversion has fewer
ghosts than another's).

Consider a file that 'shows up' after a ghost merge. We don't know when
in the ghost ancestry the file was added, or if it was just added in the
 merge revision. So we set the last-modified to THIS. However, someone
who had that merge without the ghosts would set the last-modified
properly to some older revision.

So when we fill those ghosts, we really should go back and update all
the inventories that now have the wrong "last-modified" value. This
applies to root entries as well. (If you have a ghost as your first
parent, which gets filled, you would then need to go to propagate the
new last modified revision to all child revisions.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknJVcMACgkQJdeBCYSNAAO6uACgjfKDfmmXUZ+Jb6Bs9h6BoYBW
LIMAn0lr2Dl39C+h3UTqxIgIb7fNGG+v
=MBt1
-----END PGP SIGNATURE-----