/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: <a rel="next" accesskey="n" href="Bisecting.html#Bisecting">Bisecting</a>,
Previous: <a rel="previous" accesskey="p" href="Exporting-to-GIT.html#Exporting-to-GIT">Exporting to GIT</a>,
Up: <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 – 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 > 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 > file2
file 2 getting in
^D
$ cat > file
ERASE
^D
$ mtn add file2
$ mtn ci -m "Two"
$ cat > 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 > PACKETS
mtn -d A automate packet_for_rdata a423db0ad651c74e41ab2529eca6f17513ccf714 >> PACKETS
mtn -d A automate packets_for_certs a423db0ad651c74e41ab2529eca6f17513ccf714 >> PACKETS
mtn -d B read < 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 > PACKETS2
mtn -d A automate packet_for_fdelta 8714e0ef31edb00e33683f575274379955b3526c 8b52d96d4fab6c1e56d6364b0a2673f4111b228e >> PACKETS2
mtn -d A automate packet_for_rdata d14e89582ad9030e1eb62f563c8721be02ca0b65 >> PACKETS2
mtn -d A automate packets_for_certs d14e89582ad9030e1eb62f563c8721be02ca0b65 >> PACKETS2
mtn -d B read < 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 > KEY_PACKETS
mtn -d B read < 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>
|