[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Introduce per-instance filesystem UUIDs

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Fri, 15 Aug 2014 14:15:41 +0400

> 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

- 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.

Evgeny Kotkov
Received on 2014-08-15 12:16:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.