On 18.08.2014 21:43, Evgeny Kotkov wrote:
> What I am really concerned about is that this internal little fix
> could ultimately become an unnecessary complicated, full-stack and
> user-visible feature. I doubt that we want users to know something
> about the way we solve our *internal* problems. Why would they ever
> need to know?
I think it's not that simple.
Consider the case where an administrator decides to not use 'svnadmin
hotcopy' to back up a repository, but instead creates a (LVM) snapshot
of the volume and uses 'tar' (or 'cp -a') to create the backup.
When such a backup is restored and made active, everything will just
work ... except that stale caches in svnserve or mor_dav_svn will not be
automatically invalidated. In other words, the mere introduction of the
instance ID does not solve "all" problems. There are several possible
resolutions to this particular problem:
* Tell the users "don't do that". That won't help; they'll do it anyway.
* Require a restart of all servers when restoring such backups; been
there, people forget.
* Require that the users run 'svnadmin recover' before bringing the
repository online; this might work if 'svnadmin recover' tweaks the
instance ID, since presumably they're already using it per our
existing recommendation.
* Invent 'svnadmin restore' or 'svnadmin activate' or whatnot to make
such backups viable; see above, people forget.
* Require 'svnadmin setuuid' on the restored backups; this breaks
existing working copies.
So, even though the existence of the instance ID is an implementation
detail, it does cause visible change in the behaviour of the repository:
server restarts due to fiddling with the repository instance are needed
far less often; but we still have to document when and why they are needed.
I don't pretend that the cases I listed above cover all the possible
side effects of introducing an instance ID. That's why I asked for a
branch, with documentation about how and why the instance ID affects
existing commands (and APIs) -- even if this documentation is only in a
BRANCH-README file and is later included in the release notes. Also, we
may decide not to implement some of the things (e.g., in svnadmin) that
constitute the "complete set" of instance-id related changes, but before
deciding which of them we can safely skip, we need an idea of what the
complete set is; again, easier to get that idea with a branch to work on
than trying to figure out what we "forgot" to implement on trunk.
IMO, the extra hassle of managing the branch is much smaller than the
extra hassle of releasing 1.9.1..1.9.5 in the first 2 months after
1.9.0, just because we forgot to implement some (in retrospect) obvious
changes on trunk before the release.
I'm sure the 1.8.0 fiasco taught us a thing or two about that; so, let's
try not to repeat it.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. br...@wandisco.com
