This file is indexed.

/usr/share/doc/monotone/html/Using-packets.html is in monotone-doc 1.0-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
<html lang="en">
<head>
<title>Using packets - monotone documentation</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="monotone documentation">
<meta name="generator" content="makeinfo 4.13">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Advanced-Uses.html#Advanced-Uses" title="Advanced Uses">
<link rel="prev" href="Exporting-to-GIT.html#Exporting-to-GIT" title="Exporting to GIT">
<link rel="next" href="Bisecting.html#Bisecting" title="Bisecting">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
  pre.display { font-family:inherit }
  pre.format  { font-family:inherit }
  pre.smalldisplay { font-family:inherit; font-size:smaller }
  pre.smallformat  { font-family:inherit; font-size:smaller }
  pre.smallexample { font-size:smaller }
  pre.smalllisp    { font-size:smaller }
  span.sc    { font-variant:small-caps }
  span.roman { font-family:serif; font-weight:normal; } 
  span.sansserif { font-family:sans-serif; font-weight:normal; } 
--></style>
<link rel="stylesheet" type="text/css" href="texinfo.css">
</head>
<body>
<div class="node">
<a name="Using-packets"></a>
<p>
Next:&nbsp;<a rel="next" accesskey="n" href="Bisecting.html#Bisecting">Bisecting</a>,
Previous:&nbsp;<a rel="previous" accesskey="p" href="Exporting-to-GIT.html#Exporting-to-GIT">Exporting to GIT</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="Advanced-Uses.html#Advanced-Uses">Advanced Uses</a>
<hr>
</div>

<h3 class="section">3.18 Using packets</h3>

<p>Suppose you made changes to your database, and want to send those
changes to someone else but for some reason you cannot use netsync.  Or
maybe you want to extract and inject individual revisions automatically
via an external program. In this case, you can convert the information
into packets. Packets are a convenient way to represent revisions and
other database contents as plain text with wrapped lines &ndash; just what
you need if you want to send them in the body of an email.

<p>This is a tutorial on how to transfer single revisions between
databases by dumping them from one database to a text file and then
reading the dump into a second database.

<p>We will create two databases, A and B, then create a few revisions in
A, and transfer part of them to B.

<p>First we initialize the databases:

<pre class="smallexample">$ mtn -d A db init
$ mtn -d B db init
</pre>
<p>Now set up a branch in A:

<pre class="smallexample">$ mtn -d A setup -b test test
</pre>
<p>And let's put some revisions in that branch:

<pre class="smallexample">$ cd test/
$ cat &gt; file
xyz
^D
$ mtn add file
$ mtn ci -m "One"    <i>You may need to select a key and type a passphrase here</i>
$ cat &gt; file2
file 2 getting in
^D
$ cat &gt; file
ERASE
^D
$ mtn add file2
$ mtn ci -m "Two"
$ cat &gt; file
THIRD
^D
$ mtn ci -m "Three"
</pre>
<p>OK, that's enough.  Let's see what we have:

<pre class="smallexample">$ cd ..
$ mtn -d A automate select i: | mtn -d A automate toposort -
a423db0ad651c74e41ab2529eca6f17513ccf714
d14e89582ad9030e1eb62f563c8721be02ca0b65
151f1fb125f19ebe11eb8bfe3a5798fcbea4e736
</pre>
<p>Three revisions! Let's transfer the first one to the database B. First we
get the meta-information on that revision:

<pre class="smallexample">$ mtn -d A automate get_revision a423db0ad651c74e41ab2529eca6f17513ccf714
format_version "1"

new_manifest [b6dbdbbe0e7f41e44d9b72f9fe29b1f1a4f47f18]

old_revision []

add_dir ""

add_file "file"
 content [8714e0ef31edb00e33683f575274379955b3526c]
</pre>
<p>OK, one file was added in this revision. We'll transfer it. Now, <em>ORDER MATTERS</em>! 
We should transfer:

     <ol type=1 start=1>
<li>The file data (fdata) and file deltas (fdeltas), if any
<li>The release data (rdata)
<li>The certs
     </ol>

<p>In that order. This is because certs make reference to release data, and release data
makes reference to file data and file deltas.

<pre class="smallexample">mtn -d A automate packet_for_fdata 8714e0ef31edb00e33683f575274379955b3526c &gt; PACKETS
mtn -d A automate packet_for_rdata a423db0ad651c74e41ab2529eca6f17513ccf714 &gt;&gt; PACKETS
mtn -d A automate packets_for_certs a423db0ad651c74e41ab2529eca6f17513ccf714 &gt;&gt; PACKETS
mtn -d B read &lt; PACKETS
</pre>
<p>This revision (a423db0ad651c74e41ab2529eca6f17513ccf714) was already sent to database
B. You may want to check the PACKETS file to see what the packets look like.

<p>Now let's transfer one more revision:

<pre class="smallexample">mtn -d A automate get_revision d14e89582ad9030e1eb62f563c8721be02ca0b65
format_version "1"

new_manifest [48a03530005d46ed9c31c8f83ad96c4fa22b8b28]

old_revision [a423db0ad651c74e41ab2529eca6f17513ccf714]

add_file "file2"
 content [d2178687226560032947c1deacb39d16a16ea5c6]

patch "file"
 from [8714e0ef31edb00e33683f575274379955b3526c]
   to [8b52d96d4fab6c1e56d6364b0a2673f4111b228e]
</pre>
<p>From what we see, in this revision we have one new file and one patch, so we do the
same we did before for them:

<pre class="smallexample">mtn -d A automate packet_for_fdata d2178687226560032947c1deacb39d16a16ea5c6 &gt; PACKETS2
mtn -d A automate packet_for_fdelta 8714e0ef31edb00e33683f575274379955b3526c 8b52d96d4fab6c1e56d6364b0a2673f4111b228e &gt;&gt; PACKETS2
mtn -d A automate packet_for_rdata d14e89582ad9030e1eb62f563c8721be02ca0b65 &gt;&gt; PACKETS2
mtn -d A automate packets_for_certs d14e89582ad9030e1eb62f563c8721be02ca0b65 &gt;&gt; PACKETS2
mtn -d B read &lt; PACKETS2
</pre>
<p>Fine. The two revisions should be in the second database now. 
Let's take a look at what's in each database:

<pre class="smallexample">$ mtn -d A automate select i: | mtn -d A automate toposort -
a423db0ad651c74e41ab2529eca6f17513ccf714
d14e89582ad9030e1eb62f563c8721be02ca0b65
151f1fb125f19ebe11eb8bfe3a5798fcbea4e736

$ mtn -d B automate select i: | mtn -d B automate toposort -
a423db0ad651c74e41ab2529eca6f17513ccf714
d14e89582ad9030e1eb62f563c8721be02ca0b65
</pre>
<p>Good! B has the two first revisions (as expected), and A has all three. However, a checkout
of that branch on B will not work, because the certificate signatures cannot be verified. 
We need to transfer the signatures too (suppose the key used had the ID <code>"johndoe@domain.com"</code>):

<pre class="smallexample">mtn -d A pubkey johndoe@domain.com &gt; KEY_PACKETS
mtn -d B read &lt; KEY_PACKETS
</pre>
<p>Done.

<pre class="smallexample">$ mtn -d B co -b test test-B
$ ls test-B
file2  _MTN  x
$ more test-B/file2
file 2 getting in
</pre>
<p>And that's it! The revisions were successfully transferred.

</body></html>