> To be constructive, I implemented the feature in the db/uuid
> instead of db/format - taking your code and commentary
> where possible. That automatically covered the dump / load
> issue and shortened the patch quite a bit. Cache keying
> and structure description update are also addressed.
>
> I did not implement an extension to 'svnadmin setuuid' to only
> update the instance ID because I'm not sure I really want it.
>
> A minor thing I did is to call the new feature 'instance ID'
> instead of 'instance UUID' because there is no need to guarantee
> global uniqueness. Our current implementation just happens
> to generate UUIDs. Future code might use something else.
> But that is a only a minor point.
Agreed. I like the approach chosen in the V2 patch, so, I did a few tweaks to
it and committed the patch in r1618138.
Worth mentioning, I found the "dump / load" part of the log message a bit
misleading. As I see it, we do not really *need* to bump the instance ID when
going through dump / load procedure. Whenever you load the dump into an empty
destination, that destination will have a unique instance ID, and nothing bad
will happen even if that instance ID survives through the svn_fs_set_uuid()
call. However, I am fine with also bumping the instance ID here, because it
is a bit simpler to implement and kind of fits the whole concept. Presumably,
it is also better in two edge cases that I could think of (from my point of
view, both of them are "broken workflows", but they are still theoretically
possible):
- Recovering from a disaster by loading an incremental dump into an old
repository snapshot with '--force-uuid', and performing a hot swap after it.
- Loading identical dumps (or different dumps, but with '--ignore-uuid') into an
empty template repository, e.g., a repository with configured hooks and common
access rights. This workflow assumes that the template repository is being
copy-pasted prior to loading something into it.
So, I tweaked this part of the log message accordingly. Hopefully, I am not
missing something crucial here. I would also like to solve the problem with
incremental hotcopy not taking the pack-lock on the destination (as mentioned
earlier), because now this should be fairly trivial.
P.S. I have reread my previous answers in this thread and I realized that they
can be considered quite arrogant. That was utterly unnecessary (it never *is*
necessary, actually), so, I am terribly sorry for that.
Regards,
Evgeny Kotkov
Received on 2014-08-15 12:16:30 CEST