Lukáš Lalinský wrote:
> Here is the problem:
>
> Most of inventories in bzr.dev have root IDs "TREE_ROOT", but a branch
> starting from
> "<email address hidden>" has
> inventories with root ID "tree_root-20070410133226-3795pjcs6oz73ncz-1".
> This branch was merged to bzr.dev without a common ancestry in revision
> "<email address hidden>". But that
> means that one parent of
> "<email address hidden>" points to
> the versioned file "%54%52%45%45_%52%4f%4f%54", the other one to
> "tree_root-20070410133226-3795pjcs6oz73ncz-1".
>
> I'm not sure what is the right solution here: either can be repositories
> that don't support rich roots normalized to ROOT_ID, or can be parents
> of "<email address hidden>" added as
> ghosts, but I think this will break other things. What I'm wondering
> about is how this could happen, though. I see that WorkingTree4
> generates a new root ID only for repositories that do support rich
> roots.
>
I believe there was some time that we generated unique ids for new projects. It
turned out to not be supported well by older clients, so we reverted that
change. But that doesn't mean people dogfooding on bzr.dev didn't happen to
create a branch or two that runs into this.
%54%52%45%45_%52%4f%4f%54 == TREE_ROOT
I think that:
if root_id == ROOT_ID or root_id.startswith('tree_root'):
# Ignore if there is a missing versioned file
It is a bit hackish, but it is working around a very unlikely case.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lukáš Lalinský wrote: 20070410133226- 3795pjcs6oz73nc z-1". 45%45_% 52%4f%4f% 54", the other one to 20070410133226- 3795pjcs6oz73nc z-1".
> Here is the problem:
>
> Most of inventories in bzr.dev have root IDs "TREE_ROOT", but a branch
> starting from
> "<email address hidden>" has
> inventories with root ID "tree_root-
> This branch was merged to bzr.dev without a common ancestry in revision
> "<email address hidden>". But that
> means that one parent of
> "<email address hidden>" points to
> the versioned file "%54%52%
> "tree_root-
>
> I'm not sure what is the right solution here: either can be repositories
> that don't support rich roots normalized to ROOT_ID, or can be parents
> of "<email address hidden>" added as
> ghosts, but I think this will break other things. What I'm wondering
> about is how this could happen, though. I see that WorkingTree4
> generates a new root ID only for repositories that do support rich
> roots.
>
I believe there was some time that we generated unique ids for new projects. It
turned out to not be supported well by older clients, so we reverted that
change. But that doesn't mean people dogfooding on bzr.dev didn't happen to
create a branch or two that runs into this.
%54%52% 45%45_% 52%4f%4f% 54 == TREE_ROOT
I think that:
if root_id == ROOT_ID or root_id. startswith( 'tree_root' ):
# Ignore if there is a missing versioned file
It is a bit hackish, but it is working around a very unlikely case.
John enigmail. mozdev. org
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFHa9ghJde BCYSNAAMRAk+ VAJ9msI2+ RXHtqUF5bdtn2M6 52S0VSwCdHmlG IdIV1ReM=
J6SkePCpKZDCgWC
=mWrU
-----END PGP SIGNATURE-----