* notes/dump-load-format.txt
Specify dump order. And describe special properties.
= How to interpret Subversion dumpfiles =
-Version 1.2, 2019-11-18
+Version 1.3, 2020-12-21
== Introduction ==
@@ -97,6 +97,11 @@ that can parse RFC-822 messages.
A revision record is followed by zero or more Node records (see below).
+Revisions are always dumped in monotonically increasing
+revision-number order. The date proprty of a revision may be
+explicitly set to any value, or even unset, but normally a sequence of
+commits will have monotonically increasing timestamps.
+
==== Node records ====
Each Revision record is followed by one or more Node records.
@@ -368,6 +373,38 @@ to delete all properties from a path, the dumpfile generator will
issue a node with an empty properties section. (This is different from
an *absent* properties section, which will change no properties.)
+=== Special properties ===
+
+svn:author::
+ Identification of the commit author, normally a Unix username on
+ the repository server.
+
+svn:date::
+ An RFC3339 UTC timestamp to millisecond precision. Here is an example:
+ "2011-11-30T16:41:55.154754Z". The length and precision of this
+ field is fixed: 27 characters with the trailing Zulu timezone
+ required.
+
+svn:log::
+ The change comment associated with this revision.
+
+The following per-node properties are interpreted by Subversion itself:
+
+svn:executable::
+ When this is set on a node, the executable bits in the metadata of
+ checkout copies corresponding file are set. On Unix systems which
+ of the x bits are set is filtered by the current umask.
+
+svn:ignore, svn:global-ignores::
+ Set ignore patterns for Subversion clients. Read the Subversion
+ manual for semantic details.
+
+svn:mergeinfo, svn:mime-type, svn:keywords, svn:eol-style, svn:externals::
+ Read the Subversion manual for semantic details.
+
+All other property settings are ignored by Subversion, but preserved
+in repositories and dump streams.
+
=== Representation of symbolic links ===
When the Subversion client sends a content blob representing a
@@ -396,7 +433,7 @@ for each revision can be discarded after it is processed unless it is
a source revision for a copyfrom, but there are cases in which doing
this will leave you unable to trace ancestry chains through copies.
-Instead, is advisable to build your filemaps using a copy-on-write
+Instead, it is advisable to build your filemaps using a copy-on-write
store.
== An example ==
