Daniel Shahaf wrote on Sat, Apr 28, 2012 at 11:27:37 +0300:
> Greg Stein wrote on Fri, Apr 27, 2012 at 23:45:12 -0400:
> > Hey Daniel,
> >
> > I had four svnadmin tests dump core due to an assertion: 8, 21, 26,
> > 27. These are all marked XFail(), so my test run "passed".
>
> AFAIK all of those are due to the same issue: dst_fs->uuid not being
> initialized. Philip noted that there are probably worse problems here,
> since fs_fs_shared_data_t (ffd->ffsd) holds various locks and caches that
> are indexed by UUID only.
We store the following data for use by >1 svn_fs_t object, where today
the sharing is keyed on UUID only:
typedef struct fs_fs_shared_data_t {
fs_fs_shared_txn_data_t *txns;
fs_fs_shared_txn_data_t *free_txn;
svn_mutex__t *txn_list_lock;
svn_mutex__t *fs_write_lock;
svn_mutex__t *txn_current_lock;
apr_pool_t *common_pool;
} fs_fs_shared_data_t;
Hotcopy needs to support ≥2 filesystem instances which have the same
contents and UUID. (Keeping the UUID is part of the API.) However,
everything above except common_pool needs to be per-instance. So, we
need some sort of per-instance identifier to use as the cache key.
So, for example, one way to proceed would be to maintain
a ${REPOS}/db/uuid2 file, which is not exposed to fs-loader.h, and which
is used as part of the key to ffd->ffsd structures.
Assuming we agree on the course, I should be able to get this
implemented this week.
