Re: [Monotone-devel] resolving name conflicts; schema_migration test broken

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> There is a format number in the revision data. It is simply hard-coded
> to "1" in revision.cc print_insane_revision; there are no comments on
> when it should be incremented. Changing it will give a nice error
> about upgrading monotone in revision.cc parse_revision; so it probably
> should be incremented.

I did this, and it broke several tests, but almost all were easily
fixed. Changing just the revision_format number changes all the
revids; fixing the tests is a matter of just using the new ones. I
made sure that was the _only_ code change when fixing these tests.

However, it broke schema_migration and workspace_migration, and I
don't see how to fix those.

Note that _only_ the tests broke; the _only _ change in the code
between the passing test (fe760bf3fd74449943698f8afd557259eea4f191)
and the failing test () is the change from
revision_format number 1 to revision_format number 2.

The problem in schema_migration is that both the revision format _and_
the database schema change during the test. Because of the change in
revision_format number, all the revids change between the two
databases that are supposed to be the same.

I think we need a way to request revision_format 1 for this test.

We could add an option for that, but it would have to go on several
commands, and might be confusing for users. Do we have a way to define
"hidden" options?

I guess I could also regenerate all the test databases, using the new
revision_format number. That seems wrong; real databases that need to
be migrated won't have that revision_format.

Or maybe there could be a migration step that changes the
revision_format in a revision? That isn't necessary otherwise.

I have not investigated the specific problem in workspace_migration;
it is even harder to follow.

--
-- Stephe