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

Re: svn commit: rev 1138 - trunk/subversion/svnadmin

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-01 23:00:43 CET

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.


"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

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.