Heh. I forgot to stick the ':)' in my first email.
Maybe it's just me, but why do you want to expose a manual interface for
optimizing the repository storage? Don't we have more important fish to
fry?
It's also not entirely clear that we know that such a thing is
necessary. I hadn't thought we'd done much performance analysis.
Contrary evidence is very welcome, but I don't recall seeing too much
about it on this list. However, I must admit that the traffic is
starting to get high enough that I can't read everything anymore.
Exposing a very complicated hammer to optimize a repository's
performance manually without doing some deep performance analysis first
makes me nervous.
Maybe this is another one of those: Bill, you missed a conversation
about this in one of the notes you accidentally didn't read. Or maybe
it's one of the things that you collab.net folks are talking internally
and forgot to let the list on what direction you guys were taking. If
so, please accept my apologies. I'm just trying to keep on top of
understanding what you guys are up to and still get my full time job
done of course. :)
Thanks,
Bill
> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> "Bill Tutt" <rassilon@lyra.org> writes:
>
> > Mike:
> > > lscr REPOS_PATH PATH
> > > Print, one-per-line and youngest-to-eldest, the revisions in
> > > which PATH was modified.
> > > (For directories, this is, for now, almost guaranteed to be
> > > uninteresting)
> >
> > Err, isn't kind of the minimal beginnings of the work that needs to
> > happen for log to become useful again?
> >
> > I always get the shivers when somebody adds some new functionality
to
> > svnadmin. We're supposed to be client/server, if the ra lib doesn't
let
> > you do it, add support for it.
>
> Whoa, down boy! This functionality will begin as
svn_fs_changed_revisions,
> which return an apr_array_header_t of revision numbers. Svnadmin will
> simply call that and print it out. This, in conjunction with
> svnadmin's deltify/undeltify, will provide excellent flexibility when
> optimizing one's repository based on "high-traffic" paths.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
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:37:03 2006