[MERGE] mv accepts paths containing symlinks #66964

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> Out of curiosity how did you fund bug #1213894, it doesn't seem like
> something you would just happen across.

I encountered it when I was writing the test cases for real_parent.
(See how they start with realpath, to show the difference between
real_parent and realpath?)

Initially, the tests failed.  I thought I was losing it.  Then I
discovered Python2.3 behaved as I expected, and so did 2.4.3 on a
another machine.

>>>I've called it real_parent.
> 
> 
> ^- Not the best name, since it sounds like you only get the parent back.
> Perhaps: path_with_real_parent(). That is a bit long, and I realize this
> is a place for bikeshedding. So think about it for a bit, and if the
> best we can think of is 'real_parent', we can go with it.

dereferenced_path? (It doesn't explain what makes it different from
realpath, but it shouldn't mislead.)

> It looks pretty good to me, though. I have the feeling this will also fix:
> https://launchpad.net/products/bzr/+bug/32669

According to my tests, it doesn't.

It appears that WorkingTree.open_containing is dereferencing the path,
but the file path isn't dereferenced.

What you would want is for neither to be dereferenced.  My patch causes
both to be dereferenced.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFQLmk0F+nu1YWqI0RAjLRAJ9wIXgUjW/Od/iDrlw725UZKWq00gCeLDiK
K26qJCOEOQt3dtCixRB+SW8=
=kCC0
-----END PGP SIGNATURE-----