branch reference does not support relative paths properly

John Meinel said this patch unlikely will go in to bzrlib, because usual practice is to introduce new format. I have no idea how new BranchReference format should be used if new format won't be default. Non-default format does not suit my needs. So if somebody ever need this patch, it's here.

So I think it would be fine to update the code to support relative paths, just not create them by default. Then we can transition.

Arguably older clients will fail "safely" in that they just won't find the reference. Except I think if you are sitting in the root dir, then they will find the relative path, and fail otherwise...

John A Meinel пишет:
> So I think it would be fine to update the code to support relative
> paths, just not create them by default. Then we can transition.
>
> Arguably older clients will fail "safely" in that they just won't find
> the reference. Except I think if you are sitting in the root dir, then
> they will find the relative path, and fail otherwise...
>

Does introducing new non-default branch reference format will help?

John A Meinel пишет:
> So I think it would be fine to update the code to support relative
> paths, just not create them by default. Then we can transition.
>
> Arguably older clients will fail "safely" in that they just won't find
> the reference. Except I think if you are sitting in the root dir, then
> they will find the relative path, and fail otherwise...
>

If new format will be non-default is it possible to use some
command-line flag of `bzr checkout --light` command to force relative
reference? Say:

bzr co --light --relative

or something similar?

If somebody will guide me how to create new format for this I may try to
finish my patch.

2009/12/2 Alexander Belchenko <email address hidden>:
> John A Meinel пишет:
>> So I think it would be fine to update the code to support relative
>> paths, just not create them by default. Then we can transition.
>>
>> Arguably older clients will fail "safely" in that they just won't find
>> the reference. Except I think if you are sitting in the root dir, then
>> they will find the relative path, and fail otherwise...
>>
>
> If new format will be non-default is it possible to use some
> command-line flag of `bzr checkout --light` command to force relative
> reference? Say:
>
> bzr co --light --relative
>
> or something similar?

Yes, I think so.

> If somebody will guide me how to create new format for this I may try to
> finish my patch.

I understood John to mean that he no longer thought a new format was
necessary. I agree with that position and so I hope that is what he
did mean. You can just update the old format code. It is possible
that old clients will be confused when they see a relative path there,
but the problem should be obvious and people can either change the
path to be absolute, or update their software.

--
Martin <http://launchpad.net/~mbp/>

It should be easy to test if old clients deal with relative paths; if
they do then there is no problem.

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.

You have to know that we don't support relative paths to know that a
relative path is the problem.

-Rob

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.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4640 (20091126) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru

-----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-----

John A Meinel пишет:
>
> 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.

BTW, Aaron's design of nested trees is also may benefits from relative
references, because IIUC his model is also using light checkouts from
some internal depot.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4469 (20090930) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru

2009/12/2 Alexander Belchenko <email address hidden>:
> 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.

It's true, but I don't think this is always actually a good tradeoff
for our users. A "unknown format" message is, I surmise from user
feedback, nearly as confusing and problematic as an error in opening
the branch reference. And it's likely to hit more people, either when
we make it a default, or when they fail to set relative paths and need
to upgrade.

We need to think about the larger issue but in this particular case I
think it may be reasonable to treat the old clients as just buggy for
not supporting it. We could presumably put a fix into 2.0.x to get it
to work?

--
Martin <http://launchpad.net/~mbp/>

I think I just fixed this in <https://code.edge.launchpad.net/~mbp/bzr/135234-checkout-relpath/+merge/21343> as bug 135234.

I'm sorry Alexander's patch stalled for so long.

It turns out that existing bzrs do in fact cope ok with relative paths there.