On Sat, 15 Jul 2006, Madan S. wrote:
> Also, on another line of thought, I was wondering why there is
> hardcoding of table names and column numbers when dealing with the sqlite
> tables. Couldn't we make these macros?
Yes, but the table structure isn't final -- makes sense to prototype
in low fidelity here.
> Redundant code chunk removal.
> (In branches/merge-tracking)
> * subversion/libsvn_fs_fs/tree.c:
> (parse_mergeinfo_from_db): Remove redundant call to apr_hash_set().
> Index: subversion/libsvn_fs_fs/tree.c
> --- subversion/libsvn_fs_fs/tree.c (revision 20681)
> +++ subversion/libsvn_fs_fs/tree.c (working copy)
> @@ -1173,9 +1173,6 @@
> if (sqlite_result != SQLITE_DONE)
> return svn_error_create(SVN_ERR_FS_SQLITE_ERROR, NULL,
> - apr_hash_set(*result, mergedfrom, APR_HASH_KEY_STRING,
> - pathranges);
This is clearly redundant. The following snippet was all added in 20091:
+ apr_hash_set(*result, mergedfrom, APR_HASH_KEY_STRING, pathranges);
+ if (sqlite_result != SQLITE_DONE)
+ return svn_error_create(SVN_ERR_FS_SQLITE_ERROR, NULL,
+ apr_hash_set(*result, mergedfrom, APR_HASH_KEY_STRING,
However, why remove the second occurrence instead of the first? If we
detect an error, wouldn't we want to fail-fast instead of setting a
possibly bogus value in the hash?
Received on Mon Jul 17 22:06:43 2006
- application/pgp-signature attachment: stored