incorrect repository detected with symlink to a branch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
High
|
Unassigned |
Bug Description
Just ran into this. The following situation will break things nastily...
bzr init-repo --trees .
bzr init tree
bzr init-repo --trees subproject
bzr init subproject/subtree
cd tree
ln -s ../subproject/
cd ../subproject/
bzr commit --unchanged -m 'foo'
cd -
bzr log link
bzr: ERROR: bzrlib.
KnitRepository(
(this is trivially demonstrated using just bzrlib, and I found this in
bzr-avahi's share command). A test for any fix for it should be a core
test not a blackbox test).
The cause is that the branch object for 'link' has not followed the
symlink - its root and its bzrdir are './link' rather than
'../subproject/
walking up the tree) the shared repository at '../subproject' is not
found, rather the shared repository at '..' is - which (of course) does
not include the revision or inventory or text data.
I think this is a critical bug, as it can trivially lead to data being
recorded in the wrong repository, and hard to diagnose glitches for
other users - it will let people think things are corrupt (when they
aren't). I also think folk have reported this on IRC but we haven't
diagnosed it correctly at the time.
affects /products/bzr
status triaged
importance critical
--
GPG key available at: <http://
Changed in bzr: | |
importance: | Critical → High |
Changed in bzr: | |
status: | Triaged → Confirmed |
This appears to have been introduced with or around urlutils: the comment for local_abspath in local.py says it calls realpath, but urlutils.py does not call realpath, instead it just does url manipulation now.