> 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
