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

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> Attached is an updated version of the patch. Now 'branch.get_parent()'
>>> will raise an InaccessibleParent error if it cannot return a full url to
>>> the parent.
>>> And then 'copy_content_into()' handles that exception when appropriate.
>>>
>>> I've added tests that all branch implementations do the right thing.
> 
> 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.
> 
> So I'm -0.
> 
> Aaron

I think you misunderstand what I changed, so I'll try to make it clearer.

In 0.8 we always used absolute paths in .bzr/branch/parent. Technically,
what we used was a mix of urls and local paths. And the local paths
would be utf-8 encoded. And theoretically so were the http:// urls, but
we never really tested anything there.

In bzr.dev we switched this to use relative urls when possible,
otherwise use an absolute url.

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)

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

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'

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.

In bzr.dev, 'baz' now stores the parent as "../bar". This has the
advantage that you can now get the parent over http, or sftp, or the
local filesystem. I think this is a pretty good benefit (which is why we
did it).

If you tried to access 'http://otherhost/bar' it would tell you the
parent is 'http://otherhost/bar/../baz' or 'http://otherhost/baz'.
Similarly over sftp: 'sftp://otherhost/var/www/http/bar/../baz' points
to the right location.


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. So you
get: file:///home/username/mybranch

But that isn't what bzr.dev does right now.

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.

I suppose you could argue that 'copy_content_into' could fall back to
using the relative path, so if it could not resolve the absolute path,
it would save the raw path, and give you
"../../../../home/username/mybranch'.

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

And then from another machine you can do

  bzr checkout --lightweight sftp://host/path/b

And now 'bzr pull', 'bzr missing', etc, all point to
'sftp://host/path/a'. Rather than in bzr-0.8 where they point to
'/path/a'. Which may or may not exist on your local filesystem.

You can now also do:
  bzr branch sftp://host/path/a sftp://host/path/b
And if checkouts worked over http, this would work:
  bzr checkout --lightweight http://host/b
  bzr missing (would point to http://host/a)

That behavior already exists in bzr.dev (it has since my encoding branch
landed).
What currently fails is doing 'bzr get http://host/b' when the parent is
not accessible over the published schema.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060801/684dccbd/attachment.pgp