Bazaar

Bug #330086
Comment #8

Comment 8 for bug 330086

Revision history for this message

John A Meinel (jameinel) wrote on 2009-12-02: Re: [Bug 330086] Re: branch reference does not support relative paths properly

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

Alexander Belchenko wrote:
> Robert Collins пишет:
>> It should be easy to test if old clients deal with relative paths; if
>> they do then there is no problem.
>
> Old clients will fail if they are running from subdir of light checkout, not from the root of the
> tree, with NotABranch error.
>
>> If they don't I think its better to issue a new format, because I don't
>> think the error will be at all obvious otherwise.
>
> New format is always safe choice according to existing practice in bzr.
>
>> You have to know that we don't support relative paths to know that a
>> relative path is the problem.
>
> Both relative path and absolute path *are* problem when either master branch or checkout
> moved/renamed in filesystem. But, relative path is the big win for recent Ian's idea of colocated
> branches placed in the shared repo inside lightweight checkout. Because that construct is clearly
> relative.
>

to be clear, current bzrlib just opens location with "Branch.open(location)"

Which means that if CWD is at the checkout, "../foo" works.

The proposed patch changes it to be:

Branch.open(urlutils.join(bzrdir.base, location))

Which means that if you are in a subdirectory of the checkout, or in a
parent directory, the relative path still works.

The argument for abspath vs relpath basically boils down to:

If you rename the checkout are you also renaming its targets.

This is true when you say, rename your whole shared repository.
($HOME/dev/repo to $HOME/dev/repo-other)

It isn't true if you just rename the working dir.

In the case of scmproj or Ian's colocated branches spec, it is probably
true more often than not, as renaming the checkout implicitly renames
all of the referenced branches.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksWgtoACgkQJdeBCYSNAAOHDACgsD+5sy2mhyuc6HKrZf2FigJV
PygAnic6F7sEQgIeoun4G34EPEtv9o4b
=Jrhh
-----END PGP SIGNATURE-----

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

Alexander Belchenko wrote:
> Robert Collins пишет:
>> It should be easy to test if old clients deal with relative paths; if
>> they do then there is no problem.
> 
> Old clients will fail if they are running from subdir of light checkout, not from the root of the
> tree, with NotABranch error.
> 
>> If they don't I think its better to issue a new format, because I don't
>> think the error will be at all obvious otherwise.
> 
> New format is always safe choice according to existing practice in bzr.
> 
>> You have to know that we don't support relative paths to know that a
>> relative path is the problem.
> 
> Both relative path and absolute path *are* problem when either master branch or checkout
> moved/renamed in filesystem. But, relative path is the big win for recent Ian's idea of colocated
> branches placed in the shared repo inside lightweight checkout. Because that construct is clearly
> relative.
>

to be clear, current bzrlib just opens location with "Branch.open(location)"

Which means that if CWD is at the checkout, "../foo" works.

The proposed patch changes it to be:

Branch.open(urlutils.join(bzrdir.base, location))

Which means that if you are in a subdirectory of the checkout, or in a
parent directory, the relative path still works.

The argument for abspath vs relpath basically boils down to:

If you rename the checkout are you also renaming its targets.

This is true when you say, rename your whole shared repository.
($HOME/dev/repo to $HOME/dev/repo-other)

It isn't true if you just rename the working dir.

In the case of scmproj or Ian's colocated branches spec, it is probably
true more often than not, as renaming the checkout implicitly renames
all of the referenced branches.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksWgtoACgkQJdeBCYSNAAOHDACgsD+5sy2mhyuc6HKrZf2FigJV
PygAnic6F7sEQgIeoun4G34EPEtv9o4b
=Jrhh
-----END PGP SIGNATURE-----