[svnbook] r5443 committed - trunk/en/book/ch03-advanced-topics.xml
cmpilato at users.sourceforge.net
cmpilato at users.sourceforge.net
Mon Oct 2 09:55:32 CDT 2017
Revision: 5443
http://sourceforge.net/p/svnbook/source/5443
Author: cmpilato
Date: 2017-10-02 14:55:31 +0000 (Mon, 02 Oct 2017)
Log Message:
-----------
* en/book/ch03-advanced-topics.xml
Note the primary reason why revision datestamps get out of order.
Suggested by: Daniel Shahaf <danielsh at apache.org>
Modified Paths:
--------------
trunk/en/book/ch03-advanced-topics.xml
Modified: trunk/en/book/ch03-advanced-topics.xml
===================================================================
--- trunk/en/book/ch03-advanced-topics.xml 2017-10-02 14:39:14 UTC (rev 5442)
+++ trunk/en/book/ch03-advanced-topics.xml 2017-10-02 14:55:31 UTC (rev 5443)
@@ -308,18 +308,24 @@
</informalexample>
<warning>
- <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
- ability to correctly convert revision dates into real
- revision numbers depends on revision datestamps maintaining
- a sequential ordering—the younger the revision, the
- 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>
+ <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 younger its datestamp. But datestamps are
+ stored in the unversioned, modifiable
+ <literal>svn:date</literal> property of the revision (see
+ <xref linkend="svn.advanced.props" />), so it is possible
+ for revision datestamps to get out of sequence. Now, most
+ of Subversion's operations are unaffected by this
+ situation—after all, the revision number itself is the
+ primary identifier of each revision. But if the datestamp
+ 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.
+ Combining the histories of multiple repositories into a
+ single one (as described in
+ <xref linkend="svn.reposadmin.maint.migrate" />) is the most
+ common cause of this scenario.</para>
</warning>
</sect2>
More information about the svnbook-dev
mailing list