[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

State of the WC-NG World

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 21 Jul 2009 21:25:25 +0200

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).

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?

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2373285
Received on 2009-07-21 21:25:46 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.