On 29.11.2013 17:46, Bert Huijben wrote:
>
> Can we please use plain text mail?
>
Sorry. Here it is again.
Return-Path: <br...@wandisco.com>
Received: from zulu.local (cpe-46-164-20-116.dynamic.amis.net. [46.164.20.116])
by mx.google.com with ESMTPSA id b42sm41883871eem.9.2013.11.29.07.50.18
for <dev@subversion.apache.org>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Fri, 29 Nov 2013 07:50:19 -0800 (PST)
Received: from zulu.local (localhost [IPv6:::1])
by zulu.local (Postfix) with ESMTP id A98BF9B2891D
for <dev@subversion.apache.org>; Fri, 29 Nov 2013 16:50:17 +0100 (CET)
Message-ID: <5298b7b9.1080...@wandisco.com>
Date: Fri, 29 Nov 2013 16:50:17 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0)
Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dev@subversion.apache.org
Subject: Re: Specifying commit timestamps over RA
References: <8761rdy8om....@ntlworld.com>
<cabw-3ycj8asvy8t+d1cd8dknj6iomxesbbyehtcmtohgh7a...@mail.gmail.com>
In-Reply-To:
<cabw-3ycj8asvy8t+d1cd8dknj6iomxesbbyehtcmtohgh7a...@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------030803050103010804020807"
This is a multi-part message in MIME format.
--------------030803050103010804020807
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On 29.11.2013 15:29, Ivan Zhakov wrote:
> On 27 November 2013 22:57, Philip Martin <philip.mar...@wandisco.com> wrote:
>> In 1.9 we have a new API svn_fs_commit_txn2 that allows 'svnadmin load'
>> to create a revision with a specified timestamp rather than having to
>> make a commit with the "wrong" date followed by a revision property
>> change to set svn:date to the correct value. WANdisco are interested in
>> making this feature available over RA so that it can be used for
>> replication. svnsync could use such an implementation to avoid having
>> to make an svn:date revision property change after each commit.
>>
> While I added svn_fs_commit_txn2() function I think it should not be
> exposed through svn_repos_* and RA layer.
>
> FS layer currently doesn't treat svn:date as special property except
> commit. And for commit operation it just an option add timestamp
> within lock to guarantee them strictly ordered. As far I remember
> Michael C. Pilato said somewhere that this intentional FS layer
> design.
>
> Repos layer is different: it relies on svn:date order in functions
> like svn_repos_dated_revision(). Repos layer has functions to load
> repository dump, but this dump supposed to be created by
> svn_repos_dump_fs() and have valid svn:date order. Adding option to
> specify custom svn:date for new revision in svn_repos() layer will
> break this invariant.
We don't have any code anywhere that would guarantee that svn:date
values are in-order, and we've known for 10 years that dated revision
searches or ranges yield indeterminate results if the dates /within the
searched subtree/ are not in order.
Other than that, it is perfectly OK for the dates to be out of order. If
you don't believe me, you only have to look at the import of the
Subversion repository into the ASF repo:
$ svn log -r0:HEAD ^/subversion --limit 1 | grep ^r
r836401 | joes | 2009-11-15 20:53:16 +0100 (Sun, 15 Nov 2009) | 1 line
$ svn log -r836402:HEAD ^/subversion --limit 1 | grep ^r
r836420 | (no author) | 2000-03-01 03:32:07 +0100 (Wed, 01 Mar 2000) | 1 line
You're also missing the entire point of the discussion: the intent of
the proposed change is to be able to sync repository mirrors in such a
way that both the contents and the revprops, including the original
svn:date value of the master repo, can be atomically committed to the
mirror. In other words, the intent is to /reduce/ the probability of
having out-of-order dates on the mirror.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
--------------030803050103010804020807
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 29.11.2013 15:29, Ivan Zhakov wrote:<br>
</div>
<blockquote
cite="mid:cabw-3ycj8asvy8t+d1cd8dknj6iomxesbbyehtcmtohgh7a...@mail.gmail.com"
type="cite">
<pre wrap="">On 27 November 2013 22:57, Philip Martin <a
class="moz-txt-link-rfc2396E"
href="mailto:philip.mar...@wandisco.com";><philip.mar...@wandisco.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In 1.9 we have a new API svn_fs_commit_txn2 that allows
'svnadmin load'
to create a revision with a specified timestamp rather than having to
make a commit with the "wrong" date followed by a revision property
change to set svn:date to the correct value. WANdisco are interested in
making this feature available over RA so that it can be used for
replication. svnsync could use such an implementation to avoid having
to make an svn:date revision property change after each commit.
</pre>
</blockquote>
<pre wrap="">While I added svn_fs_commit_txn2() function I think it
should not be
exposed through svn_repos_* and RA layer.
FS layer currently doesn't treat svn:date as special property except
commit. And for commit operation it just an option add timestamp
within lock to guarantee them strictly ordered. As far I remember
Michael C. Pilato said somewhere that this intentional FS layer
design.
Repos layer is different: it relies on svn:date order in functions
like svn_repos_dated_revision(). Repos layer has functions to load
repository dump, but this dump supposed to be created by
svn_repos_dump_fs() and have valid svn:date order. Adding option to
specify custom svn:date for new revision in svn_repos() layer will
break this invariant.</pre>
</blockquote>
<br>
We don't have any code anywhere that would guarantee that svn:date
values are in-order, and we've known for 10 years that dated
revision searches or ranges yield indeterminate results if the dates
<i>within the searched subtree</i> are not in order.<br>
<br>
Other than that, it is perfectly OK for the dates to be out of
order. If you don't believe me, you only have to look at the import
of the Subversion repository into the ASF repo:<br>
<pre>$ svn log -r0:HEAD ^/subversion --limit 1 | grep ^r
r836401 | joes | 2009-11-15 20:53:16 +0100 (Sun, 15 Nov 2009) | 1 line
$ svn log -r836402:HEAD ^/subversion --limit 1 | grep ^r
r836420 | (no author) | 2000-03-01 03:32:07 +0100 (Wed, 01 Mar 2000) | 1 line
</pre>
<blockquote
cite="mid:cabw-3ycj8asvy8t+d1cd8dknj6iomxesbbyehtcmtohgh7a...@mail.gmail.com"
type="cite">
</blockquote>
<br>
You're also missing the entire point of the discussion: the intent
of the proposed change is to be able to sync repository mirrors in
such a way that both the contents and the revprops, including the
original svn:date value of the master repo, can be atomically
committed to the mirror. In other words, the intent is to <i>reduce</i>
the probability of having out-of-order dates on the mirror.<br>
<br>
-- Brane<br>
<br>
<div class="moz-signature">-- <br>
<span style="font-face:sans-serif;font-size:9pt;line-height:18pt">Branko
Čibej <span style="color: #f90">|</span> <span
style="font-weight:bold">Director of Subversion</span>
<br>
WANdisco <span style="color: #f90">//</span> <span
style="font-style:oblique">Non-Stop Data</span>
<br>
<span style="color: #ccc">e.</span> <a class="moz-txt-link-abbreviated"
href="mailto:br...@wandisco.com";>br...@wandisco.com</a></span></div>
</body>
</html>
--------------030803050103010804020807--
