In general, completely agree with you, Bill. However, a couple of
things argue for an exception here:
1) The bulk of this work is in the new libsvn_fs function to list
changed revs for a node. This is needed for other svn
functionality, such as log, so it needs to get done sooner
rather than later. (The rest of the logic for fixing log is a
bit more complex, so will happen separately.)
2) The rest of Mike's change is a bone simple mod to svnlook or
svnadmin, given the new libsvn_fs function. Might as well do it
now -- if nothing else, it provides an easy way to *test* the
libsvn_fs stuff!
So, while the need for more performance analysis hasn't gone away,
this is still a change whose time has come IMHO.
-K
"Bill Tutt" <rassilon@lyra.org> writes:
> 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