[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; schema_migration test bro
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] resolving name conflicts; schema_migration test broken |
Date: |
Sat, 17 May 2008 18:19:58 -0400 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt) |
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