view tests/test-convert-bzr-ghosts.t @ 23401:fd1bab28a8cc stable

manifest: fix a bug where working copy file 'add' mark was buggy

Because the same dictionary was used to (1) get node from parent and (2) store
annotated version, we could end up with buggy values. For example with a chain
of renames:

  $ hg mv b c
  $ hg mv a b

The value from 'b' would be updated as "<old-a>a", then the value of c would be
updated as "<old-b>a'. With the current dictionary sharing this ends up with:

    '<new-c>' == '<old-a>aa'

This value is double-wrong as we should use '<old-b>' and a single 'a'.

We now use a read-only value for lookup. The 'test-rename.t' test is impacted
because such a chained added file is suddenly detected as such.

  $ . "$TESTDIR/bzr-definitions"
  $ cat > ghostcreator.py <<EOF
  > import sys
  > from bzrlib import workingtree
  > wt = workingtree.WorkingTree.open('.')
  > 
  > message, ghostrev = sys.argv[1:]
  > wt.set_parent_ids(wt.get_parent_ids() + [ghostrev])
  > wt.commit(message)
  > EOF

ghost revisions

  $ mkdir test-ghost-revisions
  $ cd test-ghost-revisions
  $ bzr init -q source
  $ cd source
  $ echo content > somefile
  $ bzr add -q somefile
  $ bzr commit -q -m 'Initial layout setup'
  $ echo morecontent >> somefile
  $ python ../../ghostcreator.py 'Commit with ghost revision' ghostrev
  $ cd ..
  $ hg convert source source-hg
  initializing destination source-hg repository
  scanning source...
  sorting...
  converting...
  1 Initial layout setup
  0 Commit with ghost revision
  $ glog -R source-hg
  o  1@source "Commit with ghost revision" files: somefile
  |
  o  0@source "Initial layout setup" files: somefile
  

  $ cd ..