On 15.11.2010 23:22, Gavin Beau Baumanis wrote:
Ping. This has received no further comments.



Gavin "Beau" Baumanis
E: gav...@thespidernet.com


On 31/10/2010, at 12:42 PM, Daniel Shahaf wrote:

Is there a reason not to apply this "let's not reinvent the wheel" patch?

[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===================================================================
--- subversion/libsvn_fs_fs/fs_fs.c     (revision 1029231)
+++ subversion/libsvn_fs_fs/fs_fs.c     (working copy)
@@ -2205,15 +2205,14 @@ read_rep_offsets(representation_t **rep_p,
  return SVN_NO_ERROR;
}

-/* Combine the revision and offset of the ID to a string that will
- * be used as a cache key. Allocations will be made from POOL.
+/* Return a string that uniquely identifies the noderev with the
+ * given ID, for use as a cache key.
*/
static const char *
get_noderev_cache_key(const svn_fs_id_t *id, apr_pool_t *pool)
{
-  return svn_fs_fs__combine_two_numbers(svn_fs_fs__id_rev(id),
-                                        svn_fs_fs__id_offset(id),
-                                        pool);
+  const svn_string_t *id_unparsed = svn_fs_fs__id_unparse(id, pool);
+  return id_unparsed->data;
}

/* Look up the NODEREV_P for ID in FS' node revsion cache. If noderev
]]]

(It does not resolve my test failures.)

Daniel
It turns out that this function is called rarely if the cache
hit rate is high. If it is low, the extra cost for id_unparse
won't be noticeable as well in comparison to the costs
of fetching the info from the file.

Committed as r1035882.

-- Stefan^2.

Reply via email to