On 08.08.2014 19:24, Evgeny Kotkov wrote:
> Hi,
>
> I would like to propose a patch for the problem discussed in
> http://svn.haxx.se/dev/archive-2014-04/0245.shtml
>
> Please see the details below.
>
> Log message:
> [[[
> Avoid shared data clashes between repositories duplicated using 'hotcopy',
> see http://svn.haxx.se/dev/archive-2014-04/0245.shtml
[...]
The idea of introducing a separate repository UUID that is "guaranteed"
to be unique has been discussed a couple times, tough maybe not on-list.
I agree that we need something like this, for the reasons you state below.
(N.B: Only "guaranteed", not actually guaranteed, because people can
still do silly things like 'svnadmin freeze repo cp -a repo newrepo'.)
[...]
> Index: subversion/libsvn_fs_fs/fs.h
> =======================================
> --- subversion/libsvn_fs_fs/fs.h (revision 1616822)
> +++ subversion/libsvn_fs_fs/fs.h (working copy)
> @@ -179,7 +179,10 @@
> extern "C" {
> /* Minimum format number that stores mergeinfo-mode flag in changed
> paths */
> #define SVN_FS_FS__MIN_MERGEINFO_IN_CHANGES_FORMAT 7
> +/* Minimum format number that supports per-instance filesystem UUIDs. */
> +#define SVN_FS_FS__MIN_INSTANCE_UUID_FORMAT 7
> +
> /* The minimum format number that supports a configuration file
> (fsfs.conf) */
> #define SVN_FS_FS__MIN_CONFIG_FILE 4
I suggest you create a branch and commit this there, so that people can
actually test with different scenarios. If and when you feel that the
branch is ready, just initiate a merge-vote on this list — see the
recent vote for merging the svn-auth-x509 branch as an example.
I think the change is serious enough that it merits being developed on a
branch, especially since I'd really like to stabilize trunk and begin
the 1.9 release cycle. This could mean that your change wouldn't make it
into 1.9.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. br...@wandisco.com
