Adding a symlink to another branch fails

A related problem is renaming a symlink, which points to another branch, fails. Basically, where symlinks point to should be considered the contents of a symlink, and bzr should never resolve them for any other purpose. Hence, bzr should always test to see if a file is a symlink before doing anything else with it (some python equivalent to lstat, sorry I'm not a python programmer).

Following the end of the reduced case above (from bug #32669):
/root # bzr rename b1/linkto_b2 b1/renamed_linkto_b2
bzr: ERROR: b1/linkto_b2 is not in the same branch as b1/linkto_b2

I'm sure the developers already now this (since the severity has been upgraded to major), but I just confirmed that this bug is still present in bzr.dev rev 1688.

The first case does work with a plain 'bzr add b1', not specifying the filename linkto_b2

As far as I recall, when I originally filed the bug, this work-around didn't work either.
I should have put it in as another explicit use case.

Thanks for the update!
I'm glad to see someone else is really interested.

Still exists in bzr.dev. 'bzr add' will do the right thing, but 'bzr add symlink' has multiple failure paths.
Several paths effectively call os.path.normpath, which will normalize all symlinks, including the final one.

osutils._posix_abspath() calls normpath,
and urlutils.local_path_to_url() calls both _posix_abspath, and normpath.

Probably we could update osutils._posix_abspath() to not normpath the final entry, and then update callers to not call normpath on the returned path

Dropping importance to medium, because you can add the symlink as long as you do 'bzr add .'

Assigning this to Aaron, because he has a recent patch which should fix this bug.

Not the same but related bug:

touch foo
bzr init branch
cd branch
mkdir dir
cd dir
ln -s ../../foo bar
bzr add bar
bzr commit -m 'Please' bar

fails with:
bzr:bzr: ERROR: Path(s) are not versioned: branch/dir/bar

but

cd ..

bzr commit -m 'Thanks' dir

works

Hello, I'm not sure this bug is solved.

Considering this files structure :
ls -l .
branch-one (hard-file branch)
branch-two (hard-file branch)
branch --> branch-one (symlink branch)

ls -l ./branch-one
(some dev files, but no symlinks inside the directory)

If I do 'cd branch && bzr status', this works fine. I think in this case that bzr has no symlink to resolve : 'bzr status' works with the '.' file, that's 'branch-one/.'.

But when I use a fresh bzr 2.0.3, latest bzr-eclipse and xmloutput plugins, I get this error in the bzr-eclipse console :
/home/path/branch is not in the same branch as /home/path/branch

As mentionned in a previous message of this bug report, the 'branch' symlink changes from one runtime to another : branch --> branch-one sometimes, but branch --> branch-two some other times.

In this case, bzr is not called from the inside of the branch directory (as it was in the previous example), but with an absolute path. In this path, symlink doesn't get resolved but is handled as a file itself. It should be handled as 'branch-one' hard-file.

It's only an hypothesis that doesn't explain much, I don't really understand where the error is.

This bug is old, and it really seems not to be solved. This is really important beeing ablse to use seemlinks on branch names, for scripting and sources organization purposes.

Thanks taking it in consideration and giving an opinion on this or a workaround in the trunk :)

The exact error issued or forwarded by the bzr-eclipse plugin, through an eclipse console, is (without double-quotes) :

" Error while executing xmlstatus
    /home/path/branch is not in the same branch as /home/path/branch"

I have one more subtle issue to add related to this bug:
- add symlinks pointing to files in another repository
- committing these explicitly fails
- commit in the parent directory is successful

The case in detail:

florian@thehoff:~/fenics/src/dolfin-cusp$ bzr st
modified:
  dolfin/la/DefaultFactory.cpp
unknown:
  dolfin/la/CuspFactory.cpp@
  dolfin/la/CuspFactory.h@
  dolfin/la/CuspMatrix.h@
  dolfin/la/CuspVector.h@
  dolfin/la/cusp.h@

florian@thehoff:~/fenics/src/dolfin-cusp$ bzr add dolfin/la/cusp.h dolfin/la/Cusp*
adding dolfin/la/cusp.h
adding dolfin/la/CuspFactory.cpp
adding dolfin/la/CuspFactory.h
adding dolfin/la/CuspFactory.os
adding dolfin/la/CuspMatrix.h
adding dolfin/la/CuspVector.h

florian@thehoff:~/fenics/src/dolfin-cusp$ bzr st
added:
  dolfin/la/CuspFactory.cpp@
  dolfin/la/CuspFactory.h@
  dolfin/la/CuspFactory.os
  dolfin/la/CuspMatrix.h@
  dolfin/la/CuspVector.h@
  dolfin/la/cusp.h@
modified:
  dolfin/la/DefaultFactory.cpp

florian@thehoff:~/fenics/src/dolfin-cusp$ bzr ci dolfin/la/cusp.h dolfin/la/Cusp* dolfin/la/DefaultFactory.cpp
bzr: ERROR: dolfin/la/cusp.h is not in the same branch as dolfin/la/cusp.h

florian@thehoff:~/fenics/src/dolfin-cusp$ bzr ci
Committing to: /home/florian/fenics/src/dolfin-cusp/
added dolfin/la/CuspFactory.cpp
added dolfin/la/CuspFactory.h
added dolfin/la/CuspFactory.os
added dolfin/la/CuspMatrix.h
added dolfin/la/CuspVector.h
modified dolfin/la/DefaultFactory.cpp
added dolfin/la/cusp.h

Florian@11, vila@8 those problems seem to be the same as bug 128562.

The fix for this in 2.0 depends on <https://code.edge.launchpad.net/~mbp/bzr/2.0-stat-symlink/+merge/30210> letting Transports work on symlink, and then <https://code.edge.launchpad.net/~mbp/bzr/32669-2.0-symlink-branch> actually fixes it.

fixed in trunk after 2.2 only

I don't think this actually is fixed in trunk.

Martin, it no longer gives an error, but it runs 'bzr add' in the target Branch. We do still need a way to say "add this symlink to the containing tree" that doesn't find the branch at "link_to_branch".
The immediate workaround is to just "bzr add" in b1, etc.

I'm guessing this isn't actually In Progress anymore, but should be re-triaged for importance.