Fossil

Check-in [d3dabbb0]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix typos in the sync documentation.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:d3dabbb08c67750a6e2d2f58e360b986d215d49a
User & Date: drh 2016-08-18 11:16:18
Context
2016-08-18
12:33
Fix the "fossil rebuild" command so that it no longer trashes the unversioned content. Add the -u option to "fossil clone" to retrieve unversioned content during the clone. check-in: a5d8548f user: drh tags: trunk
11:16
Fix typos in the sync documentation. check-in: d3dabbb0 user: drh tags: trunk
11:03
Make sure auto-hyperlink works for anonymous. check-in: a2730fea user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/sync.wiki.

419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
...
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
...
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
does not match, it sends uvigot cards for every unversioned file that it
holds.  The client will use this information to figure out which
unversioned files need to be synchronized.
The server might also send a uvigot card when it receives a uvgimme card
but its reply message size is already oversized and hence unable to hold
the usual uvfile reply.

<p>When a client receives a "uvigot" card, it checks to see if the the
file needs to be transfered from client to server or from server to client.
If a client-to-server transmission is needed, the client schedules that
transfer to occur on a subsequent HTTP request.  If a server-to-client
transfer is needed, then the client sends a "uvgimme" card back to the
server to request the file content.

<h3>3.7 Gimme Cards</h3>
................................................................................
<blockquote>
<b>uvgimme</b> <i>name</i>
</blockquote>

<p>The <i>name</i> is the name of the unversioned file found on the
server that the client would like to have.  When a server sees a
uvgimme card, it normally responses with a uvfile card, though it might
also send anoter uvigot card if the HTTP reply is already oversized.

<h3>3.8 Cookie Cards</h3>

<p>A cookie card can be used by a server to record a small amount
of state information on a client.  The server sends a cookie to the
client.  The client sends the same cookie back to the server on
its next request.  The cookie card has a single argument which
................................................................................
<p>A schematic of an unversioned file synchronization is as follows:

<ol>
<li>The client sends a "pragma uv-hash" card to the server.  The argument
    to the uv-hash pragma is a hash of all filesnames, mtimes, and
    content hashes for the unversioned files held by the client.
    <hr>
<li>If the unversion content hash from the client matches the unversioned
    content hash on the server, then nothing needs to be done and the
    server no-ops.  But if the hashes are different, then the server
    replies with either a uv-pull-only or a uv-push-ok pragma followed by
    uvigot cards for all unversioned files held on the server.
    <hr>
<li>The client examines the uvigot cards received from the server and
    determines which unversioned files need to be exchanged in order







|







 







|







 







|







419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
...
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
...
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
does not match, it sends uvigot cards for every unversioned file that it
holds.  The client will use this information to figure out which
unversioned files need to be synchronized.
The server might also send a uvigot card when it receives a uvgimme card
but its reply message size is already oversized and hence unable to hold
the usual uvfile reply.

<p>When a client receives a "uvigot" card, it checks to see if the
file needs to be transfered from client to server or from server to client.
If a client-to-server transmission is needed, the client schedules that
transfer to occur on a subsequent HTTP request.  If a server-to-client
transfer is needed, then the client sends a "uvgimme" card back to the
server to request the file content.

<h3>3.7 Gimme Cards</h3>
................................................................................
<blockquote>
<b>uvgimme</b> <i>name</i>
</blockquote>

<p>The <i>name</i> is the name of the unversioned file found on the
server that the client would like to have.  When a server sees a
uvgimme card, it normally responses with a uvfile card, though it might
also send another uvigot card if the HTTP reply is already oversized.

<h3>3.8 Cookie Cards</h3>

<p>A cookie card can be used by a server to record a small amount
of state information on a client.  The server sends a cookie to the
client.  The client sends the same cookie back to the server on
its next request.  The cookie card has a single argument which
................................................................................
<p>A schematic of an unversioned file synchronization is as follows:

<ol>
<li>The client sends a "pragma uv-hash" card to the server.  The argument
    to the uv-hash pragma is a hash of all filesnames, mtimes, and
    content hashes for the unversioned files held by the client.
    <hr>
<li>If the unversioned content hash from the client matches the unversioned
    content hash on the server, then nothing needs to be done and the
    server no-ops.  But if the hashes are different, then the server
    replies with either a uv-pull-only or a uv-push-ok pragma followed by
    uvigot cards for all unversioned files held on the server.
    <hr>
<li>The client examines the uvigot cards received from the server and
    determines which unversioned files need to be exchanged in order