On Jul 21, 2009, at 12:25 PM, Greg Stein wrote:
> Hey all,
>
> Over the past couple months, I haven't had a chance to work on wc-ng
> due to travel and getting married and whatnot. Hyrum has been pulling
> all the weight of wc-ng lately. But I'm trying to dig back in and
> continue pushing it forward.
>
> Right now, two of the big goals in the work are:
> 1) remove all usage of svn_wc_entry_t
> 2) remove all usage of svn_wc_adm_access_t
>
> The entry_t structure needs to disappear because it doesn't model the
> working copy very well. We've been using APIs from wc_db.h internally,
> and we do not (yet) have any kind of analogue to entry_t in the svn_wc
> API. We may end up making a very limited structure available, or
> create APIs like wc_db where there are lots of OUT parameters rather
> than a structure (which allows for optional data requests). We've been
> pushing along on the assumption of "no replacement" and will see where
> that goes.
>
> The access_t structure is disappearing because we no longer require
> per-directory locks/state/cache to operate on a working copy. It is
> being replaced with svn_wc_context_t which is constructed once and
> used for all operations across all directories and even across
> distinct working copies. Essentially, a process can create one at
> startup and use it for all calls.
>
> Once we get rid of the entry_t and access_t usage, then we'll have
> removed the primary vestiges of the old working copy, and will be move
> things around "underneath" to have a single .svn subdirectory at the
> root of a working copy (rather than a .svn per directory).
Getting rid of the adm_access batons and entry_t usages is fairly
straightforward at this point, and lends itself to a hight degree of
parallelization. I'd like to see as many people as possible get
involved. It would help get people aware of the wc_db APIs, and also
help us get to 1.7 sooner.
> Another big change is removing the old "loggy" mechanism in favor of a
> sqlite-based queue of operations to perform (essentially where we need
> to "transact" changes across sqlite and the filesystem).
>
> libsvn_wc will always have some references to entry_t and access_t for
> backwards compatibility purposes (to support the old APIs). However,
> as a rough measure of how much additional work is needed, the # uses
> of each data type in libsvn_wc are:
> svn_wc_entry_t 246
> svn_wc_adm_access_t 475
>
> And they should be removed entirely in libsvn_client, but the counts
> are:
> svn_wc_entry_t 110
> svn_wc_adm_access_t 218
>
>
> The overall point here is that a lot of work is still ahead of us. I
> also have to contend with a move from Brussels back to the USA over
> the next two months. I believe that we're going to be busy on this
> until at least the end of October.
>
> For 1.6, we started to hold back new feature development and
> stabilized the codbase starting in early November. There was a lot of
> tree conflict work to finish, and so 1.6 took four months to
> stabilize, wrap, and ship (in early March). I don't think that we're
> going to need that much time to wrap since the wc-ng work "should be"
> done before we begin the wrap process. I would guess that we could
> ship 1.7 right before Christmas, or maybe right after New Year's.
>
> Part of the reason that I'm writing this is to discuss whether that
> timeframe works. We had a sorta goal of "6 month release cycle", but
> this would be about 9 months.
>
> Thoughts? Concerns?
We also need to handle moving pristine storage around, and a few under-
the-hood things like moving properties into the Sqlite DB and making
the format upgrade code a bit more robust.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2373372
Received on 2009-07-21 22:19:54 CEST