You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Rall <dl...@collab.net> on 2006/08/01 16:41:34 UTC

Re: svn commit: r20893 - branches/merge-tracking/subversion/libsvn_fs_fs

On Mon, 31 Jul 2006, Kamesh Jayachandran wrote:

> Daniel Rall wrote:
> >On Fri, 28 Jul 2006, Kamesh Jayachandran wrote:
> >
> >  
> >>Daniel Rall wrote:
> >>    
> >>>Okay -- we need to always do the cleanup, 'cuz if we don't we could
> >>>leave stray records around the merge info index.  Which don't actively
> >>>harm anything, but perhaps should be deleted...
> >>>
> >>>The API probably shouldn't be named index_merge_info(), then.
> >>>update_merge_info() would be better, but is already taken.  Should we
> >>>merge the two routines into a single routine, or rename the existing
> >>>update_merge_info() function to something more specific?
> >>>
> >>> 
> >>>      
> >>Find the attached patch.
> >>    
> >
> >I've committed a variation of this in r20923 which uses slightly less
> >SQL-y function names.
> >
> >I take it you didn't like the idea of merging the merge info index
> >entry point function you added and the function which loops over any
> >merge info for a transaction?
>
> I overlooked at it, will see it through.

While conceptually it's fine, I'm worried that it might hurt
comprehensibility, since it'll make a rather large single function out
of two separate functions which are nicely modularized (though have
only one caller each).