Colocated branch support progress - preserving characters in URLs

[Jelmer Vernooij]

On Wed, 2011-08-03 at 09:57 -0400, Gordon Tyler wrote:
> 

> I'm not trying to bikeshed here but this seems to have relevance to
> actual technical issues encountered during implementation...

>  
> Why use commas? Why not use a URL fragment to separate location from
> branch name?
>  
>   bzr+ssh://host/path/to/repo#branch
>  
> Looks a lot better to me than
>  
>   bzr+ssh://host/path/to/repo,branch

The bit after the # isn't actually sent to the server, which makes it
impossible to e.g. address branches over HTTP that way when opening them
in a browser.

A hash also requires escaping in a lot of shells, which makes it
inconvenient to use for local paths.
 
> And it allows you to avoid this issue of encoding/decoding commas.
Instead it adds the issue of encoding/decoding hashes. I'm not sure if
that really makes much difference.

Cheers,

Jelmer


> 
> On 8/2/2011 8:14 PM, Jelmer Vernooij wrote:
> > The ability to address colocated branches using URLs has long been
> in
> > progress (https://bugs.launchpad.net/bugs/380871). After
> brainstorming a
> > bit with John and Martin at the recent Launchpad sprint, I'm finally
> > back on track hacking on it.
> >
> > There are basically four things left to do now:
> >
> > 1) Avoid URLescaping comma's when converting local paths to URLs.
> > (lp:~jelmer/bzr/escape-comments)
> > 2) Preserve the distinction between literal and delimiting comma's
> in
> > URLs when they are parsed in e.g. ConnectedTransport (2)
> > 3) Parse the subsegment parameters for Transports and make them
> > accessible (done, lp:~jelmer/bzr/transport-segments)
> > 4) Look at the transport segment parameters in ControlDir and use
> them
> > to determine the default branch (this should be fairly easy)
> >
> > I'm wondering how exactly to do (2). At the moment when we receive a
> URL
> > we parse it and then urlunescape all characters. Among other things,
> > this means that urlencoded characters won't be distinguisable from
> > literal characters.
> >
> > So far, this distinction hasn't really mattered as we didn't have a
> > different interpretation for them.
> >
> > To make sure we don't lose this information, I would like to stop
> > urlunescaping things like ConnectedTransport._path,
> > ConnectedTransport._username, etc and instead urlunescape it later.
> Does
> > that seem reasonable, or is there perhaps a better way to work
> around
> > the current limitations I haven't considered?
> >
> > Cheers,
> >
> > Jelmer
>  
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>  
> iQEcBAEBAgAGBQJOOVPnAAoJEIrPJfWinA2uSUIH/juyW6LuLVcg/qEe5E0SBW80
> HhFY6GkL1OMTTBLm1jQ2xfcJK01E/OmqKqqS7Jlsen8gZhBA7zqDGBoA0en+etrQ
> 6YIk91zpAE9XgFv0bInUGgvYPybCRIfrcghfpivg0DkjckAZydkki5qra8CjiThG
> ErmEDd0r9K1Tkg73c2RHgJm/977OMkr2RtFbm9H9SU8yhW+GYcDmZnxaUyfCTb1K
> YNrVSC7VN40AMAZW+eLm8A54NOqvg8/961rAin4Kk4iIQhUf+QwUWk04Y/SuRGt3
> YWWHiWuOmgc9q/RLbwmPUHnDmqXvVApyYdLVrd/nb7VPs9ssdd83/GMYpAuokOw=
> =xxOO
> -----END PGP SIGNATURE-----
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110803/c1863bb6/attachment.pgp>