Okay, we now know fixes for all the showstopper bugs. Mike has
already checked in one, and we know what to do for issue #463.
Quick summary of issue #463 and its implications, for those who
haven't been reading my novels lately: Due to the (current) expense of
undeltification, we came up with a rewrite of the commit system that
entirely avoids undeltifying. This is such a win that it would be
worth doing even if undeltification were already as cheap as it one
day will be; as it is, such a commit rewrite is *necessary* if one
wants to commit from a behind-date working copy to a repository that's
using deltified storage.
Discussing this situation on the phone just now, Greg Stein asked a
very provocative question, herewith paraphrased:
"Why do we need deltification turned on for M3? We were going to
write an admin tool to control deltification anyway, let's just
make that a higher priority post-M3, and use the time from now to
M3 for more thorough testing of what we have. This way we don't
have the risk of writing and testing a whole new commit system
before M3, too."
I sputtered in reply:
"But, but... we can't *do* that! It's shameful!"
Greg:
<telephone equivalent of raising a single eyebrow>
Me:
"Um, okay, so you're right."
Greg's right. We should use the time between now and Thursday to do
several things:
- Move to Berkeley DB 3.3, since that appears to solve some hanging
mutex problems we encountered during earlier testing (using 3.2)
regarding simultaneous accesses to the database
- Test thoroughly over DAV.
- Test with the authorization system turned on.
- Test.
- Test.
This also gives us (hello, Brane) the luxury of considering the best
way to represent deltified nodes for our upcoming improved
undeltification method. The current representation may be fine, or
may want adjusting. The current state is that deltifying is
well-tested and correct as far as the data goes; undeltifying is also
fairly well-tested and now correct -- thanks, Mike Pilato -- but not
nearly efficient enough. There are many possible solutions to this
problem, and no reason to try to rush one in before M3.
Finally, this way we know we won't have to re-import or otherwise
recreate the repository after M3... at least not for deltification
reasons :-). When we have the right representation, and the code's
all ready, we'll just run
for rev in 1..N; do svnadmin --deltify $rev /path/to/repos; done
and that's that. Presto shrinko.
But there's absolutely no reason to hold M3 on that. So we're
shooting for Thursday, with a "light freeze" until then -- try not to
rewrite the working copy library, but minor bugfixes and changes are
fine.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006