[merge] allow 'bzr branch' even if parent is not accessible

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>>To me, this looks like you've taken something that used to work fine in
>>0.8 and made it fail in 0.9.
>>
>>In 0.8, I could access a branch by sftp, and if its parent was a local
>>path, I could also access its parent.

> I think you misunderstand what I changed, so I'll try to make it clearer.
...
> Which means if you do:
>   bzr branch . sftp://foo/bar/
> 
> The foo/bar branch would get a parent of "file:///local/path". (I don't
> really like this, but it is what we do)

I do like this, because it preserves as much information as we can.

> We weren't able to do 'bzr branch . sftp://other' in 0.8, so it isn't
> really relevant.

Well, we were able to push, which is similar.  Doesn't push set the parent?

> The real reason to switch to relative urls, is because they *can* work
> across transports. So if I ssh to 'foo' and do:
> 'bzr branch bar baz'

Okay, that is nice, when it works.

> In 0.8 the 'baz' branch would get a parent of '/var/www/http/bar'. This
> is not accessible over *any* transport except for the local system.

> I suppose if you accessed it over sftp, and your local machine has an
> identical configuration to the remote machine, it would try to access
> your local branch. Which is technically incorrect (they may not be in
> sync), but might be useful for you.

It would be correct if I mirrored up a branch.

> There is a downside, and that is what I'm fixing here. If you do:
> 
> bzr branch $HOME/mybranch /var/www/http/public_branch
> 
> Now 'public_branch' has a parent of ../../../../home/username/mybranch.
> 
> Which is not accessible over any transport except the local filesystem.
> Now, I would probably argue that if you have a relative url, which spans
> the entire filesystem, it should be turned into an absolute path.

I'd be against mixing the modes.  Relative and absolute paths behave
differently when you move branches around.  We should aim for consistent
behaviour.

> So the problem with the above code, is that at this point doing 'bzr
> branch http://otherhost/public_branch' will try to access:
>   http://otherhost/public_branch/../../../../home/username/mybranch
> 
> Which is not valid.

But if it were an absolute file path, it might be valid.

> I think having the ability to use a relative path helps a lot.
> Especially when using repositories, because now the parent probably
> points to the correct location, regardless of the transport you use to
> access it.
> 
> For example, you can now do:
> 
>   bzr branch /path/a /path/b

But this is not something anyone does explicitly.  It's implicit, and
because of that, it's more flaky.  It will work if both branches are
public, but that's not necessarily the case.

If you really want it the parent to be publically accessible, you can do
bzr branch http://domain/path/a /path/b.

When some paths are relative and others are absolute, a user never knows
whether moving a branch around will break pull.

> That behavior already exists in bzr.dev (it has since my encoding branch
> landed).

Right, and when I saying you'd broken something that used to work, I was
including the encoding work and this latest patch.  Using urls
everywhere was a great thing.  Going to relative ones doesn't seem so
good to me.

Don't get me wrong, I'm not vetoing this.  I'm abstaining.  Someone else
can +1 it if they think it's great.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEz5IE0F+nu1YWqI0RAv+MAJ9grL7mLKttum1w71HADCdoDwgcqQCeLpfu
bnHoIqYW3+oM4qcHHDz2sis=
=Jeb1
-----END PGP SIGNATURE-----