monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] encapsulation branch plans


From: Zack Weinberg
Subject: [Monotone-devel] encapsulation branch plans
Date: Fri, 1 Feb 2008 17:53:12 -0500

On Fri, Feb 1, 2008 at 4:45 PM, Markus Schiltknecht <address@hidden> wrote:
>  > (on
>  > .experiment.encapsulation, but I hope to be done with that and merge
>  > it Real Soon).
>
>  What are your plans there? I'm still seeing app_state.hh referenced from
>  lots of files, even in places, where we could remove it, for example:
>  *** database.cc 40c9ed9bdbf10b11ed05b19b41e26b198f6c7099
>  --- database.cc 0797db2c719528424be8c3ddfccc52fe256d28ce
[...]

Aheh.  I should have made that change as part of my last commit, but I
forgot. :-)  Please go ahead and apply it.

My current plan goes like this: first, I want to refactor keys.cc and
key_store.cc to eliminate as many of the wrappers exposed by key_store
as possible.  This will involve moving functions in keys.cc to become
key_store methods (as I've already done with make_signature), moving
state from the app_state to the key_store (specifically, the agent
object), and changing some functions to take the options or lua_hooks
object as a parameter (as I did e.g. with guess_branch).

Once that's done, it will be practical to remove most of the
sub-objects of app_state, instead constructing them from the options
and/or lua objects within the CMD functions.

Once *that*'s done, I might just go ahead and merge the branch, but
the way forward from that is to get rid of app_state altogether; I
think most of its methods can go to the options object, or else be
plain functions in monotone.cc.  I think it may also make sense to
merge the lua_hooks and options objects.

This is a lot of work still, yes.  By saying "Real Soon" I didn't mean
to imply that the branch itself was almost done, only that I don't
expect it will take me many more days to get there.

>  Part of the motivation for removing the app_state was reducing the
>  amount of .hh files to include - and thus reduce the total lines of code
>  to compile per .cc file. Have you ever checked what effect that had?

I am not in a position to do build-time performance testing right now,
unfortunately.

>  How can I help you, to make that branch land on mainline?

You could figure out what the heck to do with the lua_state ->
app_state map in lua_hooks.cc?  I was going to leave it alone until
everything else was done and then turn it into a lua_state -> options
map, but I welcome better ideas. :-)

zw




reply via email to

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