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

Re: svn commit: r32977 - trunk/subversion/libsvn_repos

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 11 Sep 2008 08:31:46 -0400

Lieven Govaerts wrote:
> cmpilato_at_tigris.org wrote:
>> Author: cmpilato
>> Date: Mon Sep 8 15:44:18 2008
>> New Revision: 32977
>> Log:
>> Fix the current early bailout of 'svn log' as exhibited during
>> `svn log -gq -r31828 file:///usr/local/svn/subversion'.
>> * subversion/libsvn_repos/log.c
>> (get_combined_mergeinfo_changes, handle_merged_revisions): Squash
>> not-a-directory errors in the same places we squash not-found errors.
>> Modified:
>> trunk/subversion/libsvn_repos/log.c
> Can you describe an easy way to reproduce this in a greek repository? I
> want to add a test but don't know the mergeinfo code well enough to
> understand what was wrong from your patch, nor from your current repro
> recipe.

Sorry, I can't quick come up with a recipe, either. The change makes sense
given the pre-existing comments:

      /* Figure out what path/rev to compare against. Ignore
         not-found errors returned by the filesystem. */

All I did was extend the errors disregarded from only SVN_FS_ERR_NOT_FOUND
(which works when its only the basename of the path that's missing) to also
include SVN_FS_ERR_NOT_DIRECTORY (which is the error you get when you can't
even get down to basename for lack of intermediate directories).

Now that I look at the recipe though, I'm wondering about the *root cause*.
 This business of masking errors might be hiding a real algorithmic problem.
 I'll spend some time looking into this (and hopefully come up with a
greek-tree recipe for you in the process).

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-09-11 14:32:38 CEST

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.