Re: [Monotone-devel] automate inventory broken

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> automate inventory is printing birth revisions for ignored files, which
> breaks the automate_inventory test. The automate_inventory_restricted
> test is also failing, which at first glance looks to be due to the same
> problem.

These tests are passing for me on MinGW. Examining the test log shows no
birth revisions for ignored files.

What platform are you running on?

Looking at the buildbots, some are failing these tests (ppc-osx104#2,
i386-suse93), but some are not (i386-win32-mingw, amd64-freebsd7,
amd64-freebsd6, x86-linux-libc, x86-linux-glibc-icc). 

I can't access the detailed test log for ppc-osx104#2; it didn't like
the 'tar' command.

Looking at the i386-suse93 test log for automate_inventory, I see this
stanza:

   path "keys/address@hidden"
fs_type "file"
  birth [891fed131ee5bf2e9c72771637b22824353613bd]
 status "unknown"

You can't have a birth revision for an unknown file!

automate_inventory_restricted is passing on that buildbot, but
automate_inventory_options is failing.

In automate_inventory_options, there is one unknown file with a birth
revision, and one ignored.

Hmm. Looking at the code, in automate.cc, there is:

static revision_id
inventory_determine_birth(inventory_item const & item,
                          roster_t const & old_roster,
                          marking_map const & old_marking)
{
  revision_id rid;
  if (old_roster.has_node(item.new_node.id))
    {
      node_t node = old_roster.get_node(item.new_node.id);
      marking_map::const_iterator m = old_marking.find(node->self);
      I(m != old_marking.end());
      marking_t mark = m->second;
      rid = mark.birth_revision;
    }
  return rid;
}

rid is not explicitly set if the 'if' condition is false. 

Does 'revision_id' have a default constructor? I can't figure out the
vocab macros.

If it doesn't have a constructor, 'rid' will have a random value from
the stack. 

It may be that the machines that are passing are doing the typical C
trick of initializing variables to zero, or we're just lucky.

So try explicitly setting rid to null (I'm not clear how to do that)
in the 'else' branch, and see if that fixes things.

-- 
-- Stephe