[MERGE] mv accepts paths containing symlinks #66964

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:

...

> It seems legitimate to me that WorkingTree.open_containing would
> traverse symlinks.  Bug https://launchpad.net/products/bzr/+bug/48444
> shows a desire for Branch.open to traverse symlinks.
> 
> So this is ambiguous:
> 
> $ ln -s ../bzr.dev mylink
> $ bzr commit -m "commit"
> 
> Is it a request to commit bzr.dev?  Or is it a request to commit mylink?
> 
> Aaron

I think you mean:

$ ln -s ../bzr.dev mylink
$ bzr add
$ bzr commit -m "commit" mylink

Yes it is ambiguous.

It was something I've been wondering about. Shell handles it by saying
'mylink' is the symlink, and 'mylink/' is the target. At least that is how:

$ ls mylink
$ ls mylink/

seems to distinguish it.

I have actually been thinking about why we do or don't change things
into absolute paths.

Meaning, why do we *have* to change everything into an absolute path,
rather than working on relative paths.

I realize we don't support file:/// URLs that are relative, but we could.

Also, when someone types 'bzr branch foo bar' they get:
bzr: ERROR: No such branch file:///home/user/current/other/foo

Even if they got
bzr: ERROR: No such branch /home/user/current/other/foo

Is that better than:
bzr: ERROR: No such branch foo

Maybe, maybe not, but it seems like a user would expect you to spit back
the path that you gave him, not some modified version of it. Even worse
is if you are sitting in a directory that has a symlink somewhere. Which
means you might get:

$ cd dev/other
$ pwd
/home/jameinel/dev/other
$ bzr branch foo bar
bzr: ERROR: No such branch /windows/c/Documents and Settings/username/My
Documents/development/other/foo

(Yes, I'm trying to be extra bad, but symlinks are often useful to let
you keep things sorted, and still have simple directory names to work with).

It may be that we just need to recognize the duality of some paths. And
keep 2 strings for each path that we access. One which is the path as
the user gave it to us, and the other is some sort of 'absolute' path.
And I think we might just reach the conclusion that it isn't worth the
effort.

Or it might be better for 'bzr' to never go through an absolute path
phase. And instead, we could make it internally aware of symlinks.

So if a user says 'bzr mv link newlink', we access it by its path, and
just rename the link. But if they say 'bzr mv link/foo link/bar', then
internally we go to 'link' and see that it is of kind InventoryLink, and
we are trying to dereference to a child, so we look up what it points
to, and fail if it is a file, or go to a child file if it is a dir.

What to do for 'bzr commit link'? Either commit the link, or the link
*and* what it points to. 'bzr commit link/' should just commit the
target, etc, etc.

This may be a point that we want to stop for a bit, take a step back,
and really look at how we want bzr to interact with symlinks, write up
some use cases, and figure out how we can make it simple enough to do in
the codebase.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFQNPtJdeBCYSNAAMRAoyMAJwLO46vss9vFtGeKC+Em5FcO/P11gCgpuQO
vNEBAvZp5DWHJAgOFoJJxps=
=Nn/4
-----END PGP SIGNATURE-----