non-existent parent revision

[John A Meinel]

David Clymer wrote:

>I just did a
>
>$ bzr pull http://www.bazaar-ng.org/bzr/bzr.dev
>
>and
>
>$ bzr upgrade
>
>on my local (pristine, rev 658) bzr branch. The pull went fine, but the upgrade failed:
>
>
>
I can confirm that this is true.
I think the problem is that the current merge code can create parents
with no sha hash. Specifically when you fill out the "pending-merges"
file it adds a revision_id but not a revision hash. So that when you
commit, you get one parent which is referenced by hash, and one parent
which is not.

Since mpool did not actually merge in the revisions into his
revision-store, he just made a reference to it, it isn't possible to
actually compute the hash for that revision (which is one reason why
upgrade fails).
The second failure, is that if you are able to create the hash, you are
changing the text of the revision (by adding the hash for the parent),
which causes it's hash to change, which then causes all other revisions
based on it, to also change their hashes (because a change to a base
will hash propagate to all children).

We can certainly decide if this is desirable behavior or not. In one
sense it is okay, because a revision also implies the complete ancestry,
so if the ancestry changes, then you must reflect that.
In another sense it is a real pain, because if the text of revisions
changes, and you have to upgrade, even just upgrading single old entry
causes all newer entries to be updated.

I'm starting to see Aaron's proposal that we have some sort of
intermediate format for computing the hash in a brighter light. At the
same time, I kind of like the fact that changing history is painful. It
means that any revision has a little bit of all of it's ancestors
contained inside of it's hash.
But I do agree with Aaron that the hash could be contained, such that if
using sha1 hashes, then the sha1 of the ancestor is used, while sha160
wouldn't see the sha1 hash, just the sha160.

I think short-term, though, that anything in 'pending-merges' should
exist in the revision-store, along with it's ancestry, and that it
should always include a hash.
The whole point of including the hash along with the id, was so that you
could prevent someone from changing their history, so that you would
apply the wrong changeset. Since those trees can now potentially be used
as bases while merging, it seems important that they be referenced properly.

Or maybe pending-merges should just be updated to include the hash as
well as the revision id. So you don't have to compute it at commit time.

John
=:->

>vezult at feanor:/usr/local/share/bzr.dev/contrib$ bzr version
>bzr (bazaar-ng) 0.0.5
>  (bzr checkout, revision 854 {mbp at sourcefrog.net-20050707102201-2d2a13a25098b101})
>Copyright 2005 Canonical Development Ltd.
>http://bazaar-ng.org/
>
>bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and
>you may use, modify and redistribute it under the terms of the GNU
>General Public License version 2 or later.
>vezult at feanor:/usr/local/share/bzr.dev/contrib$ bzr upgrade
>\ [======================================= ] upgrading revision 835/854 0:00:00bzr: [Errno 2] No such file or directory: '/usr/local/share/bzr.dev/.bzr/revision-store/aaron.bentley at utoronto.ca-20050706170931-9d2551019af3578d'
>  at /usr/local/share/bzr.dev/bzrlib/store.py:181 in __getitem__()
>  see ~/.bzr.log for debug information
>
>Investigating a bit, I found that a revision-store
>(mbp at sourcefrog.net-20050707080216-4e4d884bcf89eb8d.gz) referenced two
>parents, one of which had no corresponding revision-store. A bzr check
>indicated a hash mismatch on the parent of the same revision.
>
>
>vezult at feanor:/usr/local/share/bzr.dev/.bzr/revision-store$ bzr check
>/ [=========================================] checking revision 846/854 0:00:00bzr: error: mismatched revision sha1 for parent {mbp at sourcefrog.net-20050707020702-0e24e478b738d4db} of {mbp at sourcefrog.net-20050707080216-4e4d884bcf89eb8d}: e17d750e032857ec57d4fb06cd84665e77b46045 vs f8ff86c5fa8b2748ad2abf126e48837f7f85d7a2
>  at /usr/local/share/bzr.dev/bzrlib/check.py:80 in check()
>  see ~/.bzr.log for debug information
>
>
>the relevant portions of my ~/.bzr.log are available at:
>
>  http://www.zettazebra.com/files/bzr.log-07092005
>
>
>-davidc
>
>
>

-------------- 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/20050709/0ac0036d/attachment.pgp