monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] RFC: workspace migration and work.cc refactor [net.veng


From: Zack Weinberg
Subject: [Monotone-devel] RFC: workspace migration and work.cc refactor [net.venge.monotone.workspace-merge.migration]
Date: Sun, 30 Jul 2006 10:22:13 -0700

I've just completed, on nvm.workspace-merge.migration, an
infrastructure for migrating workspace metadata formats.  As proof of
concept, it recognizes workspaces from pre-0.26 that still have the
bookkeeping directory named "MT".  I wanted to implement migration for
them, but it turns out not to be possible - the associated database
flag day changes all the revision IDs and there's no programmatic way
to update /revision.  But at least you get friendly, detailed,
apologetic error messages!

You may be wondering what the point of this infrastructure is, if
there's nothing it can do but spew error messages, and I explain that
over on nvm.workspace-merge.api there is an actual incompatible change
to the bookkeeping directory; this infrastructure will handle that.
Nathaniel being out of town for a bit, I intend to proceed with
merging .migration to .api and hooking up the migrator for that
change.

Also on this branch is a massive refactor of work.cc.  I didn't *need*
to do that for this change, but it wanted doing, and now I have a much
better handle on what work.cc does.  A question about that: I
introduced a "workspace" sub-object of app_state.  This currently has
no data of its own, but I do have future plans that involve its having
data.  However, what it does have is references to the database and
lua_hooks objects.  This allows most, but not all, of the work APIs
not to take an app_state reference as an argument.  I notice that
database and lua_hooks themselves hold references -- to the entire
app_state object.  If I did that in work, then all of the app_state
arguments could go away; on the other hand, there's a degree of extra
documentation in just which methods do take those pointers.  Which is
preferred?

zw




reply via email to

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