mv command cannot be used outside of bzr

[Nicholas Allen]

I read on the bzr web page that one can use OS command like mv and rm. If I rename a file with mv then bzr does not realize the file is renamed. Instead it lists it as an unknown file.
I believe that in Unix every file has a unique identifier that can be used to detect that the file was moved. This would be a really great feature as then the revision history could be preserved when a file is renamed/moved.

[John Dong (jdong)]

inode number... Yes, that could be used to track renames, but that'd harm our portability.

Perhaps we should just take out the part about using os mv?

[Michael Ellerman (michael-ellerman)]

What you could do is use the hash to spot when a file is moved and not modified. But doing that would be pretty expensive, and might sometimes be confusing.

So I don't think you want to do it automatically, but you could have a command that runs through and tries to spot renames after the fact.

[John Dong (jdong)]

I don't think we should do it automatically. Status commit and diff
operations are slow enough the way it is; we don't need the additional
burden

[Robert Collins (lifeless)]

On Sun, 2006-05-21 at 02:46 +0000, Michael Ellerman wrote:
> What you could do is use the hash to spot when a file is moved and not
> modified. But doing that would be pretty expensive, and might sometimes
> be confusing.

And wrong from time to time. A better approach is IMO the inode. If the
inode is the inode of a file known from the cache, and the datestamp
makes it a cache hit, then its a good candidate for 'this has been
moved'.

> So I don't think you want to do it automatically, but you could have a
> command that runs through and tries to spot renames after the fact.

I think having a command to detect renames for you is good. +1 on that.
I think having bzr notice and 'just record it' is terrible UI wise. -1
on that. (for the same reason that 'bzr add' is good, but bzr auto
adding would be bad; and bzr commit should complain on deleted files
rather than auto-deleting).

Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Martin Pool (mbp)]

On 20 May 2006, John Dong <email address hidden> wrote:
> inode number... Yes, that could be used to track renames, but that'd
> harm our portability.

It's not so much about portability as that it won't always be reliable.

> Perhaps we should just take out the part about using os mv?

Where is that?

Perhaps the text actually means that you can manipulate *branches* using mv
and rm?

--
Martin Pool

[John Dong (jdong)]

I believe it's in the web documentation.

On 5/23/06, Martin Pool <email address hidden> wrote:
>
> On 20 May 2006, John Dong <email address hidden> wrote:
> > inode number... Yes, that could be used to track renames, but that'd
> > harm our portability.
>
> It's not so much about portability as that it won't always be reliable.
>
> > Perhaps we should just take out the part about using os mv?
>
> Where is that?
>
> Perhaps the text actually means that you can manipulate *branches* using
> mv
> and rm?
>
> --
> Martin Pool
>
> --
> mv command cannot be used outside of bzr
> https://launchpad.net/bugs/45720
>