monotone-devel
[Top][All Lists]
Advanced

[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: Sun, 18 May 2008 11:45:07 -0400
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt)

"Zack Weinberg" <address@hidden> writes:

> On Sat, May 17, 2008 at 6:19 PM, Stephen Leake
> <address@hidden> wrote:
>> 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.
>
> I haven't been following this discussion very closely, so I don't know
> what you changed in the revision format, but that's beside the
> point.

The format is extended to support file suturing, which is needed for
duplicate name conflict resolution (and is also useful on its own).
The new format is a strict superset of the old.

> Can you make it so that monotone generates revision_format 2 *only if*
> the revision itself has content unrepresentable in format 1?

That's a good idea.

The format number would have to be 2 if any sutures are in the
revision edges; otherwise it can be 1.

Currently, the format number is put in the revision string first, then
all the edges are put in.

The required revision_format isn't known until the edges are printed.
Ah; I can scan the edges first, and find the max revision number
needed. That should be fast.

(later) - implemented, and working. 

> That should make this problem vanish, and also maximizes
> interoperability - we have netsync compatibility between old and new
> as long as you don't try to transfer a revision with the new thing.

Right; if you regenerate an old revision for any reason, you get the
same revid back. Which is a Good Thing, and the violation of this
invariant is the root problem in all the test failures.

It also means the 3 hrs I put in yesterday updating the tests to use
the revision_format 2 revids was wasted. Oh well :).

--
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]