You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2005/11/03 01:45:12 UTC

[PATCH] Remove unused functions [was: Sharing libsvn_fs_* internals]

Greg Hudson wrote:
> On Wed, 2005-11-02 at 13:33 +0000, Julian Foad wrote:
> 
>>To recap, I'm talking about the two files subversion/libsvn_fs_{base,fs}/err.c 
>>being almost identical.
> 
> Note that most of the functions in libsvn_fs_fs/err.c are not used.

Good grief - so they're not.  And a few in libsvn_fs_base/err.c too.

The attached patch removes them.

> Prior to the addition of lock.c, there were only four uses of the error
> helpers in all of FSFS.
> 
> Also note that having error helper functions degrades the utility of
> file and line numbers in the --enable-maintainer-mode messages, and is
> not a practice we use widely outside the FS code.

Yes - I thought it was a bit odd, but I'm not going to be the one to change it.


>>It's not just those files.  Presumably, if the two filesystems use the same set 
>>of error messages, then there is much in common in their implementation.  I 
>>haven't looked further in detail.
> 
> Although the FSFS code is based off the BDB code, I don't think there's
> much code to share (there's a path canonicalization function and some
> key generation functions, which shouldn't exist).  Much of the shared

Good grief - stuff that "shouldn't exist"!  The attached patch removes the 
completely unused key-generation functions, but doesn't address those that are 
still being used but shouldn't be.

> logic is at the higher levels ("how to open a path"), but calls out to
> different logic at the lower levels ("how to open a node-rev and read
> directory entries").  It's possible to share higher-level logic with
> lower-level differences, but it tends to be more awkward than sharing
> lower-level logic.
> 
> Also, there's a fair amount of cleanup which could be done to the FSFS
> code which would render a lot of the BDB code vestigial.  For instance,
> the dag layer doesn't really do much in FSFS, although eliminating it
> would take some doing.

Well, it would be worth cleaning up the FSFS code now that it's intended to be 
widely used and supported.  Any volunteers?


>>At the moment, while I'd be happy to go the clean, layered, potentially public 
>>route, I don't think the amount of sharing is large enough to require that, and 
>>so I'd be happy to put more shared stuff in libsvn_fs which is simpler in the 
>>short term, as long as we keep our eyes open for the point when it starts to 
>>get unreasonably complex and do the refactoring then.
> 
> We actually did put small amounts of shared code into libsvn_fs
> initially, but ran into problems on OSX and Windows.

Thanks for these words of wisdom and experience, Greg.

- Julian

Re: [PATCH] Remove unused functions [was: Sharing libsvn_fs_* internals]

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-11-03 at 01:45 +0000, Julian Foad wrote:
> > Although the FSFS code is based off the BDB code, I don't think there's
> > much code to share (there's a path canonicalization function and some
> > key generation functions, which shouldn't exist).  Much of the shared
> 
> Good grief - stuff that "shouldn't exist"!

Sorry, I have no idea why I wrote "which shouldn't exist" in that
parenthetical.  The key generation functions should exist as far as I
know.  I think I meant to say that those don't amount to much code, and
my brain wandered.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org