Greg Stein wrote:
> A couple high-level questions:
>
> 1) there is a need for some server-side tools:
> a) create a repository
> b) optimize/garbage-collect an existing repository
> c) print/purge pending/discarded transactions
> d) etc
>
> I'd like to create subversion/server/ to hold these tools. I'm not sure
> if we would have one, or whether we'd have a subcommand like the client.
> But the main point is a directory to hold the tool(s).
We already have a tools directory, off of the top level. I'd rather put
that in tools/server than cerate a new directory for such things.
> 2) APRUTIL is being put together as a sister project to APR. I'd like to
> propose using it for the following features: MD5/SHA1 hashing (MD5 is
> currently in APR itself, but it will probably move), some XML utility
> functions (and I'd like to shift some of ours over to APRUTIL), the DBM
> facilities, and possibly the URI stuff.
>
> The base64 encoding/decoding stuff is there, but it wasn't applicable to
> our needs. I'd like to look into resolving some of that (upgrading the
> base64 support in APRUTIL and/or shifting some of our support there).
We have too many base64 implementations now. There's one in Subversion,
one in neon and one in APRUTIL ... I'd go for shifting whatever is
needed to support SVN into APRUTIL and throw our implemetation away.
(No, GregH, I'm not implying you did a bad job of it, just that we don't
want to have too many copies of that stuff. :-) )
I'm getting strong urges to take neon apart and put it together again on
top of APR, but I've got other things to do right now. If Joe agrees to
that, we'll need a volunteer ...
Oh BTW, Greg, isn't there going to be some XML stuff in APRUTIL, too? I
think I saw some discussion about that on the APR list. More duplication.
> Strictly speaking, our dependency on it would be pretty light.
> mod_dav_svn can just use APRUTIL via Apache itself.
Yes, but we need base64 in the delta encoder, and md5 in the filesystem.
> However, the FS and
> the server tool(s) will need MD5 hashing and DBM support (the latter
> because mod_dav_svn will use DBM for some stuff, and the tool will need
> to deal with those).
> [ if Berkeley DB utils were exported from FS, then I'd probably use that;
> even better is to add DB3 support to APRUTIL's DBM support. ]
Definitely +1 on that last. The other option is to simply use DB3
directly; after all, it will always be distributed with the server.
Wouldn't it look weird if we used two different dbm implementations in
Subversion?
> I'm a bit light on rationale for this, but figured it would be good to
> bring up now.
>
>
> Input/thoughts appreciated...
Well, it's definitely a good thing to have stand-alone administrative
tools for managing the repository. I think these tools would use
libsvn_fs, like the command line client uses libsvn_client. In fact that
would be a good thing: the filesystem must already know how to do a good
bit of that administration, and if it learned to do the rest, you could
administer it while online, without having to lock the repository or
block readers.
in the "etc." category, it would be nice to have a tool that could
atomically pull out a set of deltas between two repository revisions.
Then you could do incremental, history-preserving backups, which is a
Good Thing.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:16 2006