Changing files to symlinks, symlinks to directories etc will cause errors.

[Stuart Bishop]

We've decided to support changing the 'type' of inventory entries but have not implemented that as yet.

[Stuart Bishop (stub)]

'bzr remove' followed by 'bzr add' on the offending filename appears to be a workaround.

[Martin Pool (mbp)]

This is a design bug. Similar things will happen if you replace a file with a directory, or any other combination. (But that's probably less common than changing a file to a symlink.)

We need to decide whether this should cause a single file-id to change kind, or whether we should assign a new file-id, or whether the file should go back to not-added.

[John A Meinel (jameinel)]

mbp wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/3720
>
> Comment:
> This is a design bug. Similar things will happen if you replace a file
> with a directory, or any other combination. (But that's probably less
> common than changing a file to a symlink.)
>
> We need to decide whether this should cause a single file-id to change
> kind, or whether we should assign a new file-id, or whether the file
> should go back to not-added.
>

I think changing a file to a directory should show up as a delete, but
not yet added, until it is done manually.

Along with this bug is the bug that "bzr mv a b" if b is in the
inventory (it was manually removed).
And the fact that if you try to re-add "a", it thinks it has already
been done.

John
=:->

[Martin Pool (mbp)]

Had a brief discussion with robertc. The easiest thing is probably to relax the constraint that file-kinds will not change for a file-id. This will have some consequences for the working directory, merge, changeset, commit, etc. Need to add tests for changing kinds in all those cases. It will probably give the best user experience, i.e. just make the change and things just work.

[John A Meinel (jameinel)]

mbp wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/3720
>
> Comment:
> Had a brief discussion with robertc. The easiest thing is probably to
> relax the constraint that file-kinds will not change for a file-id.
> This will have some consequences for the working directory, merge,
> changeset, commit, etc. Need to add tests for changing kinds in all
> those cases. It will probably give the best user experience, i.e. just
> make the change and things just work.
>

So how do you three way merge a file which changes into a directory?
Or a directory into a symlink?

I suppose they both have a revision property, so you can try and do
something smart about it. But in general, I think you are just going to
get a conflict.

I think it makes more sense to just treat the file as deleted (since it
technically was), and let the user re-add the directory.

John
=:->

[Aaron Bentley (abentley)]

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

John A Meinel wrote:
> So how do you three way merge a file which changes into a directory?
> Or a directory into a symlink?

As long as both sides agree about the change, it will work.

It's the same ol' three way logic, but it includes both type and
contents/target.

That is, create_directory == create_directory
CreateSymlink("foo") == CreateSymlink("foo")
CreateSymlink("foo") != CreateSymlink("bar")
CreateFile("foo") == CreateFile("foo")
CreateFile("foo") != CreateFile("bar")

If you change a directory into a file in THIS, and into a symlink in
OTHER, you get

filename.BASE (file)
filename.OTHER (symlink)
filename.THIS (directory)

The result is similar if both branches convert a file into a symlink,
but with different targets.

> I suppose they both have a revision property, so you can try and do
> something smart about it. But in general, I think you are just going to
> get a conflict.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDZk7w0F+nu1YWqI0RAlBaAJ0Sjg0DdEB/5z8TYURTLLKDwAEE+QCfbZ4T
ks/XeUlVKgqZFJXur9+nI2M=
=lQFC
-----END PGP SIGNATURE-----

[Kevin Smith (ubuntu-qualitycode)]

Until this is "fixed", would it be possible to at least detect it, and display a friendly message to the user? When this hit me, I had absolutely no idea what had happened or how to work around it, and then I wasted nearly an hour isolating a small test case so I could file a bug report (#3893 which ended up as a duplicate because this report didn't mention "assertion failed", so didn't show up in my search).

The problem can be worked around by removing the old file, and then adding the new file, so bzr should list the problem file(s) and propose this workaround. At least that way, the repo becomes usable again, and the user isn't left thinking their repo is trashed (and that bzr is unstable).

[John A Meinel (jameinel)]

I agree, right now we do a simple assert failure, which needs to be at first changed into a meaningful error, so that you can figure out what is going on.

I'll look into a patch for it.

[John A Meinel (jameinel)]

There are 2 different errors, depending on how you get there.

First you have:

bzr init
touch a
bzr add a
### bzr commit -m a
rm a
mkdir a
bzr st

With the commit you get:
bzr: ERROR: assertion failed:
  command: '/Users/jameinel/bin/bzr' 'st'
      pwd: u'/Users/jameinel/,tmp/a'
    error: exceptions.AssertionError
  at /Users/jameinel/dev/bzr/bzr.dev/bzrlib/inventory.py line 503, in detect_changes()
  see ~/.bzr.log for debug information

Without the commit you get:
$ bzr st
added:
  a
bzr: ERROR: Internal check failed: file u'/Users/jameinel/,tmp/a/a' entered as kind 'file' id 'a-20051105142800-ae999a761c7b4e5c', now of kind 'directory'
  command: '/Users/jameinel/bin/bzr' 'st'
      pwd: u'/Users/jameinel/,tmp/a'
    error: bzrlib.errors.BzrCheckError
  at /Users/jameinel/dev/bzr/bzr.dev/bzrlib/workingtree.py line 289, in descend()
  see ~/.bzr.log for debug information

Which I believe is the desired error. I think we just need to track down the different paths that are accessing the list of files, and see where they are expecting it not to change, and why it wasn't checked first. (I think I've also seen a case where it fails because it tries to 'open' the directory to get the contents).

[Martin Pool (mbp)]

Quite nasty when it does bite.

Aaron's tree transform code apparently handles this kind of change more safely.

Possibly needs a spec to say just how it will be handled - consensus seems to be that entries can change kind over time.

[John A Meinel (jameinel)]

We now always get 'Internal check failed' for both code paths.
Which is an improvement, but we still don't support changing the file kind. If you 'bzr rm' the file, and then 'bzr add' the directory, it seems to be okay. So for now it is probably a reasonable workaround.

[Wouter van Heyst (larstiq)]

Ahem, take more care when triaging late at night.

[Aaron Bentley (abentley)]

Merge, status, commit all work properly across kind changes. We can handle other bugs as they arise.