ch03: log -r {DATE}: state the most likely reason

Daniel Shahaf danielsh at
Sat Feb 25 02:30:20 CST 2017

Someone just asked on users@ about the -r {DATE} binary search issue,
and I realized the warning box doesn't describe the most likely cause of
that (svnadmin load).

I suppose the warning box might want to grow an id="" attribute.

Feel free to tweak.  I left the first hunk unreflowed to make the diff



Index: ch03-advanced-topics.xml
--- ch03-advanced-topics.xml	(revision 5302)
+++ ch03-advanced-topics.xml	(working copy)
@@ -308,11 +308,7 @@
-        <para>Since the timestamp of a revision is stored as an
-          unversioned, modifiable property of the revision (see <xref
-          linkend="svn.advanced.props" />), revision timestamps can be
-          changed to represent complete falsifications of true
-          chronology, or even removed altogether.  Subversion's
+        <para>Subversion's
           ability to correctly convert revision dates into real
           revision numbers depends on revision datestamps maintaining
           a sequential ordering—the younger the revision, the
@@ -319,7 +315,15 @@
           younger its timestamp.  If this ordering isn't maintained,
           you will likely find that trying to use dates to specify
           revision ranges in your repository doesn't always return the
-          data you might have expected.</para>
+          data you might have expected.
+          The <literal>svn:date</literal> timestamps are stored in
+          unversioned, modifiable property of the revision (see <xref
+            linkend="svn.advanced.props" />).  The most common reason
+          for them to be unordered is loading history into an existing
+          repository (see <xref linkend="svn.reposadmin.maint.migrate"
+            />).
+        </para>

More information about the svnbook-dev mailing list