"Using Saved Location: foo"

[Martin Pool]

On 28/04/2006, at 12:55 AM, John Arbash Meinel wrote:

> Aaron Bentley wrote:
>> John Arbash Meinel wrote:
>>> But for local file URLs, it seems like it would be nicer to  
>>> display the
>>> actual Unicode path.
>>
>> Makes sense to me.

I think we want a method that gives the "best display form" for a URL  
in the current user encoding.

For we will *try* to decode them as utf-8 and then put them into the  
user encoding.  If that's not possible, we just use the regular URL  
form.  In more detail: scan for escape sequences, and work out what  
byte they represent.  If it's a byte that has special meaning in URLs  
[/?,;#&%+ ] then leave it alone, otherwise unescape it.  Now try to  
decode as UTF-8, and then check that the result is representable in  
the user encoding - if either of those fail, leave it as an escaped  
URL.  Obviously this needs to be symmetric with the algorithm for  
turning url-like unicode strings into real URLs, and I think it is.

> So should this just be a check which says "if
> url.startswith('file:///'):" or should we be trying to do it for  
> any URL.

I think we might as well do it for regular URLs too.
>

> I would probably say that if someone used a unicode name, they want to
> see it as much as possible, because it will mean something to them,
> rather than just a bunch of gobbledygook.
>
> So I think we should display unescaped "urls" as much as possible.  
> (Yes
> they are not real urls, but they are close).

Right.
>
> Now, doing so violates the "support urls that aren't unicode"  
> principle
> that we have been talking about. But I think the violation is worth it
> for the user.

Strictly it's "support urls on servers that don't use utf-8".  If  
they're in a non-UTF-8 encoding, then they probably won't decode and  
can be displayed as a hex sequence, so people are no worse off.

>>> It would save "../otherr" as the parent, even though the pull  
>>> would fail.
>>> I changed the code to wait until the other branch has been  
>>> connected,
>>> and then use "branch.base". Which returns the absolute path.
>>>
>>> Is it better to have ".bzr/branch/parent" be exactly what the  
>>> user typed
>>> (a relative path, etc). And is it better to do it right away  
>>> rather than
>>> after we have successfully contacted the other branch?
>>
>> I think absolute paths will be correct more often, but there may be
>> times when relative paths make sense, e.g. branches provided over
>> network filesystems.
>
> Well, for everything except local we require absolute URLs. But I can
> see your point that I might have an NFS mount, and on different  
> machines
> the absolute path would be different.
>
> But then again, is that likely to be a situation where one would be  
> the
> parent, and one would be the child?
>
> I would be okay with it but I would like to see a consensus.

John, Robert and I talked about this on irc.

A related issue is that if you do a pull while cwd is in a  
subdirectory of a branch, the relative path stored should not be the  
one you typed, but rather the relative path from the root of your  
branch.

There may be some slightly tricky cases caused by symlinks.

Branch APIs that deal with locations (e.g. Branch.base) should return  
urls, even for local branches.

The parent is also a URL or relative reference.  That means that it  
can be e.g. "../bzr.dev", but it is escaped as a URL.  Setting the  
parent will work like this:

  - get the base url of the new parent
  - find the relative path from the current branch's url to that url,  
if possible.  If the urls are in different schemes or hosts, or are  
different from the first component of the path, then store the  
absolute url.

Also, the memory transport should be updated to use urls like  
memory:///foo, to be consistent with file urls.

> What is your opinion about whether we should set parent even if we are
> unable to connect to the branch?

There's a conflict between:

  - should be able to set it without using it yet
  - shouldn't permanently get stuck if someone happens to make a typo

-- 
Martin