commands that remember paths should remember whether the user gave an absolute or relative path

[Jari Aalto]

DESCRIPTION

    Local checkout command records absolute paths even in relative
    checkout situation. This means that the checkout is unmovable to
    another directory.

AN EXAMPLE

    Directory hierarchy:

        /usr/share/development
          |
          +- my-tools/
          |
          +- one/one-1.0/
          +- two/two-1.23/
          +- three/three-2.0.1/

    At one/one-1.0 directory and likewise in every other package
    directory:

          $ bzr co ../../my-toools

    Then, there is need to move the project:

        mv /usr/share/development /usr/share/ports/development
                                            =======

COMMENTS

    All the relative checkous become invalid when directories are moved.
    Another exmaple woud be:

        - A package is downloaded
        - A port is tried (tools "'checked out" into it)
        - If success, move whole project to "good" directory
          If failure, move to staging "bad" or "todo" directory for
          further examination.

    To bzr to remember and use relative paths (IF user used those), would
    be very important.

[Martin Pool (mbp)]

It would be useful if the master branch could be recorded as a relative path. In the meantime, you should be able to update to the new location after moving with 'bzr bind NEW_PATH'

[Martin Pool (mbp)]

Existing bzr versions do cope properly with relative paths there so all we have to do is store them.

Also if the 'location' file has a trailing newline, bzr tries to use it as part of the url, which is silly. We should trim it. (You can quote it as %0a if you really want it.)

[Martin Pool (mbp)]

On 15 March 2010 02:51, Jari Aalto <email address hidden> wrote:
>
> Is there any progress with this bug report:
>
>    LP#135234
>    Checkout should record relative paths (dir move problem)
>
> This is pretty desperate situation not to be able to relocate
> directories around.

Hi,

It's not trivial to store a relative path only if the user gave one,
because by the time it is stored we're often passing an object rather
than just a string. However
<https://code.edge.launchpad.net/~mbp/bzr/135234-checkout-relpath/+merge/21343>
makes it store a relative path always, which I think is reasonable.

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

[Aaron Bentley (abentley)]

Have you considered the case where the checkout is moved, but the bzr branch stays in the same place? That case is better served by using absolute locations. I am not aware of any data about the relative frequencies of these cases, but my gut says it's more common to move only the checkout than to move both (while retaining their relative positions).

[Martin Pool (mbp)]

On 25 March 2010 06:30, Aaron Bentley <email address hidden> wrote:
> Have you considered the case where the checkout is moved, but the bzr
> branch stays in the same place?  That case is better served by using
> absolute locations.  I am not aware of any data about the relative
> frequencies of these cases, but my gut says it's more common to move
> only the checkout than to move both (while retaining their relative
> positions).

I don't know how common it is, but it could happen.

I was originally going to use the URL given on the command line, but
that turns out to be a bit harder to implement because the location is
ultimately set by passing objects who only know their absolute path.

The patch is not yet merged; I won't merge it until this is settled.

https://code.edge.launchpad.net/~mbp/bzr/135234-checkout-relpath/+merge/21343

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

[Jari Aalto (jari-aalto)]

> Have you considered the case where the checkout is moved, but the bzr branch stays in the same place?

I think the file level operations should work without hick-ups:

  $  mv repo.bzr /other/location/in/disk

This way tarring up files and directories. moving them around, works like with any other directory.

I think it is reasonable to assume that the way user writes the URL to clone is preserver "AS IS". If he wants absolute paths, he uses absolute paths in the URL.

  $ bzr clone ../tools.bzr tools # relative
  $bzr clone $(pwd)/tools.bzr tools # absolute

This is especially important when making branches under a share repository where relative paths are used 99.9% of the time. Without the relative paths, the shared repository ROOT is immovable (if I understand correct) with mv(1) to another location on disk (disk full, reorganization, etc).

E.g. Git stores clone information as user types it in .git/config

[Martin Pool (mbp)]

On 28 March 2010 20:50, Jari Aalto <email address hidden> wrote:
>> Have you considered the case where the checkout is moved, but the bzr
> branch stays in the same place?
>
> I think the file level operations should work without hick-ups:
>
>  $  mv repo.bzr  /other/location/in/disk
>
> This way tarring up files and directories. moving them around, works
> like with any other directory.
>
> I think it is reasonable to assume that the way user writes the URL to
> clone is preserver "AS IS". If he wants absolute paths, he uses absolute
> paths in the URL.
>
>  $ bzr clone ../tools.bzr tools             # relative
>  $bzr clone $(pwd)/tools.bzr tools   # absolute

I think that would be reasonable too. It looks like the branch
drafted here is not an overall improvement then.

Also, the original request was about checkouts but it seems reasonable
to actually want this done for everything that takes and remembers a
path?

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

[Jari Aalto (jari-aalto)]

> ...want this done for everything that takes and remembers a path?

Yes, the example was for "checkout" command, but similarly for "branch" commands etc. This way the program preserves what "the user intended".

[Alexander Belchenko (bialix)]

I have the use case when absolute path for light checkout master branch prevents me to work with the light checkout at all.

I have 2 windows machines in the LAN. The disk of one machine mapped to another one as Z: drive. SO I can work with the remote machine as with local disk.

I have colo workspace with light checkout on remote machine. Of course it uses absolute path and this path points to C:\some\path.

If I try to work with this colo workspace as with object resides on Z: I can't do anything, because light checkout has recorded master branch as the one on disk C:, not Z:. I can't do anything there, at all.

[Aaron Bentley (abentley)]

On 03/28/2010 05:50 AM, Jari Aalto wrote:
>> Have you considered the case where the checkout is moved, but the bzr
> branch stays in the same place?
>
> I think the file level operations should work without hick-ups:
>
> $ mv repo.bzr /other/location/in/disk

A key benefit of checkouts is that they allow you to separate your
working tree from your repository. In such a situation, the specified
command will *always* break things.

> This way tarring up files and directories. moving them around, works
> like with any other directory.
>
> I think it is reasonable to assume that the way user writes the URL to
> clone is preserver "AS IS".

I don't. I think it's very easy for users to screw that sort of thing
up. We have thought about the implications, and the user usually hasn't.

We have always recorded interpreted values everywhere. On *nix, we
can't avoid this, because the shell does some of the interpretation.

Aaron

[Aaron Bentley (abentley)]

On 03/28/2010 05:50 AM, Jari Aalto wrote:
>> Have you considered the case where the checkout is moved, but the bzr
> branch stays in the same place?
>
> I think the file level operations should work without hick-ups:
>
> $ mv repo.bzr /other/location/in/disk

A key benefit of checkouts is that they allow you to separate your
working tree from your repository. In such a situation, the specified
command will *always* break things.

> This way tarring up files and directories. moving them around, works
> like with any other directory.
>
> I think it is reasonable to assume that the way user writes the URL to
> clone is preserver "AS IS".

I don't. I think it's very easy for users to screw that sort of thing
up. We have thought about the implications, and the user usually hasn't.

We have always recorded interpreted values everywhere. On *nix, we
can't avoid this, because the shell does some of the interpretation.

I think we should not introduce inconsistency here.

Aaron

[Vincent Ladeuil (vila)]

As an additional data point, relative paths can be put manually in config files but then, they are interpreted against the current working directory.
Most of the time, the current working directory *is* the branch root path but when it's not... many things can break.