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

Re: dos about revisions (was Re: manual nit)

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2001-11-26 19:31:27 CET

Ben Collins-Sussman <sussman@collab.net> writes:
> "Perry E. Metzger" <perry@wasabisystems.com> writes:
>
> > As long as they're being mentioned, I must confess to being a bit
> > confused about svn revisions. I've been playing a bit and can't quite
> > figure out how to do some things I'm used to in CVS. For instance,
> > when I do an "svn log IDEAS" in the checked-out SVN repo, I expected
> > to see all the changes made to IDEAS, but instead I saw all changes
> > ever made to the repository (!?).
>
> We turned off the behavior you expect, because the repository's
> undeltification is a bit.... slow.... right now. We're working on
> it. But normally, 'svn log foo.c' will work the way you expect.

Yup. Perry (or anyone else), if you'd like more detail, see this
comment in libsvn_repos/log.c:svn_repos_get_log():

      /* ### Below, we discover changed paths if the user requested
         them (i.e., "svn log -v" means `discover_changed_paths' will
         be non-zero here), OR if we're filtering on paths, in which
         case we use changed_paths to determine whether or not to even
         invoke the log receiver on this log item.

         Note that there is another, more efficient way to filter by
         path. Instead of looking at every revision, and eliminating
         those that didn't change any of the paths in question, you
         start at `start', and grab the fs node for every path in
         paths. Check the created rev field; if any of them equal
         `start', include this log item. Then jump immediately to the
         next highest/lowest created-rev field of any path in paths,
         and do the same thing, until you jump to a rev that's beyond
         `end'. Premature optimization right now, however.
      */

That "more efficient way" is probably still a premature optimization,
believe it or not. The only reason we disabled the current way right
now is because we're waiting for a chance to make some performance
improvements to the filesystem's undeltification, improvements which
are necessary for *many* things, not just good log behavior.

-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:49 2006

This is an archived mail posted to the Subversion Dev mailing list.