You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Blair Zajac <bl...@orcaware.com> on 2007/11/09 18:38:43 UTC

Re: svn commit: r27741 - in trunk/subversion: include libsvn_fs libsvn_fs_base libsvn_fs_fs tests/libsvn_fs

cmpilato@tigris.org wrote:
> Author: cmpilato
> Date: Fri Nov  9 08:58:14 2007
> New Revision: 27741
> 
> Log:
> Finish issue #3017 by adding a new svn_fs_node_origin_rev() API.
> 

> +   WARNING:  Do *not* call this from inside a trail. */
> +static svn_error_t *
> +prev_location(const char **prev_path,
> +              svn_revnum_t *prev_rev,
> +              svn_fs_t *fs,
> +              svn_fs_root_t *root,
> +              const char *path,
> +              apr_pool_t *pool)
> +{
> +  const char *copy_path, *copy_src_path, *remainder = "";
> +  svn_fs_root_t *copy_root;
> +  svn_revnum_t copy_src_rev;
> +
> +  /* Ask about the most recent copy which affected PATH@REVISION.  If
> +     there was no such copy, we're done.  */
> +  SVN_ERR(svn_fs_closest_copy(&copy_root, &copy_path, root, path, pool));

As a style question, if you're in libsvn_fs_base or libsvn_fs_fs, why do you 
call back through to svn_fs to call svn_fs_closest_copy and go through the 
vtable again?

Blair

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

Re: svn commit: r27741 - in trunk/subversion: include libsvn_fs libsvn_fs_base libsvn_fs_fs tests/libsvn_fs

Posted by "C. Michael Pilato" <cm...@collab.net>.
Blair Zajac wrote:
> As a style question, if you're in libsvn_fs_base or libsvn_fs_fs, why do
> you call back through to svn_fs to call svn_fs_closest_copy and go
> through the vtable again?

Good question.  I'll fix that.

But for your reference (and others'), in the BDB case it can be downright
dangerous to call the public FS functions from inside this library.  One
must be careful not to create nested Berkeley DB transactions, else suffer
deadlocks and code hangs.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand