Branching not (directly) possible from a colocated repository
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| bzr-colo |
High
|
Unassigned |
Bug Description
When I attempt to branch a branch stored within a shared repository, I receive an error message that it is not a branch:
anise:desktop mbt$ bzr colo-fetch colo:bzr+
Password:
bzr: ERROR: Not a branch: "/home/
But of course, that is a branch:
mbt@aloe ~/Projects/
Repository branch (format: 2a)
Location:
shared repository: /home/mbt/
repository branch: .
Related branches:
parent branch: /home/mbt/
Note that this is not the branch that I found this bug with, but it appears to be easily replicated for all branches.
I have received this error when attempting to use bzr 2.2.4 and bzr 2.3.0 with bzr-colo 0.2.1 and bzr-colo 0.3.0dev revision ID <email address hidden>, on multiple operating systems.
Michael B. Trausch (mtrausch) wrote : | #2 |
As I mentioned already, this happens with all branches.
These branches have never been relocated, and I use them daily on the workstation that they are on. The "bzr info" output for one of them is included in the original report, but here is both it and 'bzr st' as well as 'bzr cbs' (aliased to colo-branches) on the branch that fails to branch:
mbt@aloe ~/Projects/
Lightweight checkout (format: 2a)
Location:
light checkout root: .
checkout of branch: .bzr/branches/
shared repository: .bzr/branches
Related branches:
parent branch: .bzr/branches/
mbt@aloe ~/Projects/
modified:
autogen.sh*
config.guess*
config.rpath*
config.sub*
debian/rules*
intl/
utils/
utils/
utils/
utils/
utils/
unknown:
data/
doc/close-
src/CloseToTr
mbt@aloe ~/Projects/
origin/trunk
* versions/0.7.5dev
This branch is in perfect working order, hence the bug report...
Changed in bzr-colo: | |
status: | Incomplete → New |
summary: |
- Branching not possible from a colocated repository + Branching not (directly) possible from a colocated repository |
Michael B. Trausch (mtrausch) wrote : | #3 |
I have found a workaround: branching from the repository without the use of the colo extension for the source works just fine, for example the following sequence of commands works just fine (output omitted for clarity):
$ bzr colo-init alltray
$ cd alltray
$ bzr branch bzr+ssh:
Also, the following single command works in the same way:
$ bzr colo-fetch bzr+ssh:
The only problem comes when using the colo: specifier to branch from the source on the remote system, such as:
$ bzr colo-fetch colo:bzr+
This is the output that is placed in ~/.bzr.log for the execution of the previous command:
Sat 2011-04-23 22:09:58 -0400
1.029 bazaar version: 2.3.0
1.029 bzr arguments: [u'colo-fetch', u'bzr+ssh:
1.419 looking for plugins in /Users/
1.439 looking for plugins in /Library/
3.888 encoding stdout as sys.stdout encoding 'UTF-8'
4.196 creating repository in file://
4.206 creating branch <bzrlib.
4.270 creating branch reference in file://
4.329 trying to create missing lock '/Users/
4.329 opening working tree '/Users/
4.383 opening working tree '/Users/
5.074 ssh implementation is OpenSSH
10.866 bzr-svn: using Subversion 1.6.15 (), Subversion API 1.6.5 (), subvertpy 0.7.5
11.017 Traceback (most recent call last):
File "/Library/
return the_callable(*args, **kwargs)
File "/Library/
ret = run(*run_argv)
File "/Library/
return self.run(
File "/Library/
return self._operation
File "/Library/
self.cleanups, self.func, *args, **kwargs)
File "/Library/
result = func(*args, **kwargs)
File "/Library/
remember=True)
File "/Library/
return self._operation
File "/Library/
self.cleanups, self.func, *args, **kwargs)
File "/Library/
...
Michael B. Trausch (mtrausch) wrote : | #4 |
Oops, I typo'd on the command. Here is the correct trace:
Sat 2011-04-23 22:12:50 -0400
0.145 bazaar version: 2.3.0
0.145 bzr arguments: [u'colo-fetch', u'colo:
0.233 looking for plugins in /Users/
0.233 looking for plugins in /Library/
0.656 encoding stdout as sys.stdout encoding 'UTF-8'
0.760 creating repository in file://
0.770 creating branch <bzrlib.
0.852 creating branch reference in file://
0.865 trying to create missing lock '/Users/
0.865 opening working tree '/Users/
1.041 opening working tree '/Users/
1.469 bzr-svn: using Subversion 1.6.15 (), Subversion API 1.6.5 (), subvertpy 0.7.5
1.879 ssh implementation is OpenSSH
4.267 Traceback (most recent call last):
File "/Library/
return the_callable(*args, **kwargs)
File "/Library/
ret = run(*run_argv)
File "/Library/
return self.run(
File "/Library/
return self._operation
File "/Library/
self.cleanups, self.func, *args, **kwargs)
File "/Library/
result = func(*args, **kwargs)
File "/Library/
remember=True)
File "/Library/
return self._operation
File "/Library/
self.cleanups, self.func, *args, **kwargs)
File "/Library/
result = func(*args, **kwargs)
File "/Library/
possible_
File "/Library/
possible_
File "/Library/
base = directories.
File "/Library/
return service(
File "/Library/
return ColocatedWorksp
File "/Library/
Neil Martinsen-Burrell (nmb) wrote : | #5 |
I can reproduce this:
$ ssh $remote_host
remote$ bzr colo-init blech
#make sure $HOME/blech doesn't exist on the local host
remote$ exit
$ bzr branch colo:bzr+
gives
bzr: ERROR: Not a branch: "/Users/
Changed in bzr-colo: | |
status: | New → Confirmed |
importance: | Undecided → High |
It looks as if the colocated branch at aloe:/home/ mbt/Projects/ desktop/ alltray may have lost touch with the branches that are stored in .bzr/branches. This can happen if colocated workspaces are moved in the filesystem, because bzr stores branche references as absolute paths. What is the output of "bzr info" and "bzr st" in /home/mbt/ Projects/ desktop/ alltray? What is the output of "bzr colo-branches" in that same directory?
If this is in fact what happened, do "bzr colo-fixup" in /home/mbt/ Projects/ desktop/ alltray.