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,
> sqlite3_errmsg(db));
> -
> - apr_hash_set(*result, mergedfrom, APR_HASH_KEY_STRING,
> - pathranges);
> }
> else
> {
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,
+ sqlite3_errmsg(db));
+
+ apr_hash_set(*result, mergedfrom, APR_HASH_KEY_STRING,
+ pathranges);.
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?
- application/pgp-signature attachment: stored
Received on Mon Jul 17 22:06:43 2006