On Aug 8, 2009, at 3:09 PM, Greg Stein wrote:
> Hey all,
>
> If you'd like to help out with wc-ng, there are a few tasks that can
> helpful.
>
> One is pretty easy: switch libsvn_wc over to the
> result_pool/scratch_pool paradigm. Some functions don't return data,
> so they'd just take a scratch_pool. Today, many of the "legacy"
> functions take a single "pool" argument -- these would have that pool
> renamed, or switched to two pools. This would help in the wc-ng work
> because we're doing the conversion as we go; this makes some of the
> revisions "more complex" because we're changing functionality *and*
> switching pool usage. Changing the pool handling can also make wc more
> memory efficient.
>
> A more complicated task is propagating the db/abspath argument pairs
> throughout the codebase, replacing the adm_access/path pairs. These
> changes can be very straightforward, but periodically blow things up
> because of adm_access craziness/subtleties. There is a lot of
> low-level plumbing around the db/abspath functionality, so this task
> is continuing to push it up/out from those lower levels.
>
> The last broad task is getting rid of the entry_t structure. This is
> not straightforward at all. The mappings from our new data structures
> to the old entry_t is not straightforward, so this will be very
> challenging. Hyrum and I would certainly appreciate help at this
> level, but it can be tough.
I'd like to echo Greg's call to action, and add a few notes of my own
concerning the development plan.
I see the rest of WC-NG development unfolding in three phases:
* centralizing metadata and finalizing disk formats
* API improvements
* library-internal churn
Centralizing metadata
---------------------
This is one of the major features of wc-ng, and something that will
require an explicit upgrade for users of older working copies. The
sooner we migrate to this, the more testing it can get, and the less
pain early adopters of development versions of 1.7 will have as we
tweak formats moving toward 1.7-final. The things I see left to do are:
- Upgrade mechanism improved
- Remove use of directory-specific access batons
- Loggy replaced with the work queue (WQ)
- Properties moved into the sqlite database
Greg's looking at the upgrade mechanism in preparation for the work
queue implementation. I'm working on access baton removal, and we
seen patches and commits from other folks along these lines, too.
Shortly, the access baton removal also depends on getting rid of
loggy, since loggy is done on a pre-directory basis, and runs within
the context of an access baton. Hopefully, by the time we're ready to
tackle those batons, the work queue will be ready.
Personally, I'd like to see us get the on-disk formats stabilized
soonest, since tweaking code is relatively painless compared to
mucking with persistent data.
API Improvements
----------------
The public working copy API has already undergone significant
revisions, primarily adding a working copy context and using local
paths explicitly in place of access batons and ambiguously relative
paths. A number of data structures still need to be rev'd to use
local paths.
We also need to remove the use of svn_wc_entry_t. Most code in
libsvn_client grabs and entry, but only uses a specific piece of data,
such as the URL or the revision information. All uses of
svn_wc_entry_t should disappear in favor of specific APIs to fetch
this information. These are currently being added to libsvn_wc/
node.c, and aren't yet part of the public API. When we know what data
is most requested by the client library, we can then evaluate how best
to expose this data through "real" public APIs.
Much of this work can be done in parallel with the access baton
removal, and it might require less domain knowledge to get involved.
It isn't one of my priorities because it isn't on the critical path
just yet, but this is a great place for folks to start getting
involved if they feel uncomfortable with some of the deeper-level stuff.
Library-internal Churn
-----------------------
Internally, we anticipate that much of libsvn_client and libsvn_wc can
be simplified using the new baton-less working copy context and
absolute paths. Strictly speaking, anything internal to the libraries
won't need to be done for 1.7, but it still work that can and should
be done eventually. These types of things include:
- the scratch_pool/result_pool changes mentioned by Greg above.
- ensuring we use absolute paths consistently throughout (no more
svn_dirent_get_absolute() calls)
There may be other places where we can optimize how we retrieve data
from the sqlite database, as well.
Well, those are my thoughts. If there are concerns or questions, fire
away. And if you can find the cycles, please chip in and help finish
WC-NG.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383963
Received on 2009-08-16 03:21:58 CEST