@@ -1,24 +1,28 @@
2−navhome: /docs
2+navhome: '/docs'
5title: Filesystem
5title: Filesystem
8# Filesystem (`%clay`)
8# Filesystem (`%clay`)
10−<div class="row"> <div class="col-md-8">
10+<div class="row">
12−Urbit has its own revision-controlled filesystem, `%clay`. `%clay` is
12+<div class="col-md-8">
13−a typed, global, referentially transparent namespace. An easy way to
14−think about it is like typed `git` with continuous sync.
16−The most common way to use `%clay` is to mount a `%clay` node in a
14+Urbit has its own revision-controlled filesystem, `%clay`. `%clay` is a
17−Unix directory. The Urbit process will watch this directory and
15+typed, global, referentially transparent namespace. An easy way to think
18−automatically record edits as changes, Dropbox style. The mounted
16+about it is like typed `git` with continuous sync.
19−directory is always at the root of your pier directory.
18+The most common way to use `%clay` is to mount a `%clay` node in a Unix
19+directory. The Urbit process will watch this directory and automatically
20+record edits as changes, Dropbox style. The mounted directory is always
21+at the root of your pier directory.
21−</div> </div>
23+</div>
23## Quickstart
27## Quickstart
@@ -28,14 +32,13 @@ Create a `%sandbox` desk based on the `%home` desk:
29 |merge %sandbox ~your-urbit %home
33 |merge %sandbox ~your-urbit %home
31−Most of the time we want to use `%clay` from Unix.
35+Most of the time we want to use `%clay` from Unix.
33Mount the entire contents of your `sandbox` desk to Unix:
37Mount the entire contents of your `sandbox` desk to Unix:
35 ~your-urbit:dojo> |mount /=sandbox=
39 ~your-urbit:dojo> |mount /=sandbox=
37−To explore the filesystem from inside Urbit `+ls` and `+cat` are
41+To explore the filesystem from inside Urbit `+ls` and `+cat` are useful:
40 ~your-urbit:dojo> +ls /=sandbox=/web
43 ~your-urbit:dojo> +ls /=sandbox=/web
@@ -50,37 +53,41 @@ Sync from your friend `~some-ship`'s `%experiment` desk to your
53−<h3 class="first child">Paths</h3>
56+<h3 class="first child">
55−A path in `%clay` is a list of URL-safe text, restricted to `[a
60+A path in `%clay` is a list of URL-safe text, restricted to
56−z]`,`[0 9]`, `.`, `-`, `_` and `~`. Formally this is a `(list knot)`
61+`[a z]`,`[0 9]`, `.`, `-`, `_` and `~`. Formally this is a `(list knot)`
57where each segment is a `@ta`.
62where each segment is a `@ta`.
59Paths can be expressed as either `/foo/bar/baz` or `[%foo %bar %baz]`.
64Paths can be expressed as either `/foo/bar/baz` or `[%foo %bar %baz]`.
60The first three segments of an urbit path are `/plot/desk/case`, for
65The first three segments of an urbit path are `/plot/desk/case`, for
61−example `/~doznec/home/1`.
66+example `/~dozbud/home/1`.
63#### Relative paths
68#### Relative paths
65Relative paths are expressed using `%` which is roughly equivalent to
70Relative paths are expressed using `%` which is roughly equivalent to
66−Unix `.`. `%%` is `..` and `%%%` is what you would expect `...` to
71+Unix `.`. `%%` is `..` and `%%%` is what you would expect `...` to be.
67−be. There are no local relative paths. `foo/bar` must be written
72+There are no local relative paths. `foo/bar` must be written
68`%/foo/bar`.
73`%/foo/bar`.
70#### Substitution
75#### Substitution
72If the default path is `/foo/bar/baz`, `/=/moo` means `/foo/moo`, and
77If the default path is `/foo/bar/baz`, `/=/moo` means `/foo/moo`, and
73−`/=/moo/=/goo` means `/foo/moo/baz/goo`. Also, instead of `/=/=/zoo`
78+`/=/moo/=/goo` means `/foo/moo/baz/goo`. Also, instead of `/=/=/zoo` or
74−or `/=/=/=/voo`, write `/==zoo` or `/===voo`.
79+`/=/=/=/voo`, write `/==zoo` or `/===voo`.
76−Most commonly this is used to avoid having to know the current
81+Most commonly this is used to avoid having to know the current revision
77−revision number in the `dojo`. Instead of writing
82+number in the `dojo`. Instead of writing
78`/~your-urbit/home/4/path/to/file` you can just write
83`/~your-urbit/home/4/path/to/file` you can just write
79`/=home=/path/to/file`.
84`/=home=/path/to/file`.
81### Revision-control
86### Revision-control
88+<h3 class="first child">
83−<h3 class="first child"><code>|mount clay-path [unix-name]</code></h3>
89+<code>|mount clay-path [unix-name]</code>
85Mount the `clay-path` at the unix mount point `unix-name`.
92Mount the `clay-path` at the unix mount point `unix-name`.
@@ -112,7 +119,8 @@ Unmounts the Unix path `/generators`.
113Merges a `beak` into a `desk` using an optional merge `strategy`.
120Merges a `beak` into a `desk` using an optional merge `strategy`.
115−A `beak` is a ship-desk-case triple, encoded as a path(`/~doznec/home/2`)
122+A `beak` is a ship-desk-case triple, encoded as a
123+path(`/~dozbud/home/2`)
117**Examples:**
125**Examples:**
@@ -127,24 +135,24 @@ Merge the `%examples` desk from `~waxbex-ribmex`
127### `|sync desk plot [plot-desk]`
135### `|sync desk plot [plot-desk]`
129Subscribe to continuous updates from remote `plot` on local `desk`.
137Subscribe to continuous updates from remote `plot` on local `desk`.
130−`plot-desk` can specify the remote `desk` name. When omitted it is
138+`plot-desk` can specify the remote `desk` name. When omitted it is
131−defaulted to being the same as `desk`. Non-comet urbits have `|sync
139+defaulted to being the same as `desk`. Non-comet urbits have
132−%home ~parent %kids` automatically set up (where `~parent` is the
140+`|sync %home ~parent %kids` automatically set up (where `~parent` is the
133−planet that issued a moon, the star that issued a planet, or the
141+planet that issued a moon, the star that issued a planet, or the galaxy
134−galaxy that issued a star).
142+that issued a star).
136**Examples:**
144**Examples:**
138− |sync %home-local ~doznec %home |sync %home ~doznec
146+ |sync %home-local ~dozbud %home |sync %home ~doznec
140### `|unsync desk plot [plot-desk]`
148### `|unsync desk plot [plot-desk]`
142Unsubscribe from updates from remote `plot` on local `desk` with
150Unsubscribe from updates from remote `plot` on local `desk` with
143−optional `plot-desk`. Arguments must match original `|sync` command.
151+optional `plot-desk`. Arguments must match original `|sync` command.
147− |unsync %home-local ~doznec %home
155+ |unsync %home-local ~dozbud %home
149### `|label desk name`
157### `|label desk name`
@@ -156,57 +164,59 @@ Example:
157### Merge strategies
165### Merge strategies
159−`%init` - Used if it's the first commit to a desk. Also can be
167+`%init` - Used if it's the first commit to a desk. Also can be used to
160−used to "reinitialize" a desk -- revision numbers keep going up,
168+"reinitialize" a desk -- revision numbers keep going up, but the new
161−but the new revision isn't necessarily a descendent of the
169+revision isn't necessarily a descendent of the previously-numbered
162−previously-numbered version, allowing merges to be rerun.
170+version, allowing merges to be rerun.
164`%this` - Keep what's in Bob's desk, but join the ancestry.
172`%this` - Keep what's in Bob's desk, but join the ancestry.
166`%that` - take what's in Alice's desk, but join the ancestry. This is
174`%that` - take what's in Alice's desk, but join the ancestry. This is
167−the reverse of `%this`. This is different from `%init` because
175+the reverse of `%this`. This is different from `%init` because the new
168−the new commit has both sides in its ancestry.
176+commit has both sides in its ancestry.
170`%fine` - "fast-forward" merge. This succeeds iff one head is in the
178`%fine` - "fast-forward" merge. This succeeds iff one head is in the
171ancestry of the other.
179ancestry of the other.
173−`%meet`, `%mate`, and `%meld` - find the most recent common ancestor
181+`%meet`, `%mate`, and `%meld` - find the most recent common ancestor to
174−to use as our merge base.
182+use as our merge base.
176A `%meet` merge only succeeds if the changes from the merge base to
184A `%meet` merge only succeeds if the changes from the merge base to
177−Alice's head (hereafter, "Alice's changes") are in different files
185+Alice's head (hereafter, "Alice's changes") are in different files than
178−than Bob's changes. In this case, the parents are both Alice's and
186+Bob's changes. In this case, the parents are both Alice's and Bob's
179−Bob's heads, and the data is the merge base plus Alice's changed files
187+heads, and the data is the merge base plus Alice's changed files plus
180−plus Bob's changed files.
188+Bob's changed files.
182A `%mate` merge attempts to merge changes to the same file when both
190A `%mate` merge attempts to merge changes to the same file when both
183−Alice and Bob change it. If the merge is clean, we use it; otherwise,
191+Alice and Bob change it. If the merge is clean, we use it; otherwise, we
184−we fail. A merge between different types of changes -- for example,
192+fail. A merge between different types of changes -- for example,
185deleting a file vs changing it -- is always a conflict. If we succeed,
193deleting a file vs changing it -- is always a conflict. If we succeed,
186−the parents are both Alice's and Bob's heads, and the data is the
194+the parents are both Alice's and Bob's heads, and the data is the merge
187−merge base plus Alice's changed files plus Bob's changed files plus
195+base plus Alice's changed files plus Bob's changed files plus the merged
188−the merged files.
196+files.
190A `%meld` merge will succeed even if there are conflicts. If there are
198A `%meld` merge will succeed even if there are conflicts. If there are
191−conflicts in a file, then we use the merge base's version of that
199+conflicts in a file, then we use the merge base's version of that file,
192−file, and we produce a set of files with conflicts. The parents are
200+and we produce a set of files with conflicts. The parents are both
193−both Alice's and Bob's heads, and the data is the merge base plus
201+Alice's and Bob's heads, and the data is the merge base plus Alice's
194−Alice's changed files plus Bob's changed files plus the successfully
202+changed files plus Bob's changed files plus the successfully merged
195−merged files plus the merge base's version of the conflicting files.
203+files plus the merge base's version of the conflicting files.
197−`%auto` - meta-strategy. Check to see if Bob's desk exists, and if it
205+`%auto` - meta-strategy. Check to see if Bob's desk exists, and if it
198−doesn't we use an `%init` merge. Otherwise, we progressively try
206+doesn't we use an `%init` merge. Otherwise, we progressively try
199−`%fine`, `%meet`, and `%mate` until one succeeds. If none succeed, we
207+`%fine`, `%meet`, and `%mate` until one succeeds. If none succeed, we
200−merge Bob's desk into a scratch desk. Then, we merge Alice's desk
208+merge Bob's desk into a scratch desk. Then, we merge Alice's desk into
201−into the scratch desk with the `%meld` option to force the merge.
209+the scratch desk with the `%meld` option to force the merge. Finally, we
202−Finally, we annotate any conflicts, if we know how.
210+annotate any conflicts, if we know how.
204### Manipulation
212### Manipulation
206−<h3 class="first child"><code>|rm path</code></h3>
214+<h3 class="first child">
215+<code>|rm path</code>
208−Remove the data at `path`. `path` must be a path to actual node, not
218+Remove the data at `path`. `path` must be a path to actual node, not a
209−a 'directory'
219+'directory'
211### `|cp to from`
221### `|cp to from`
@@ -216,14 +226,16 @@ Copy the file at `from` into the path `to`.
217Move the file at `from` into the path `to`.
227Move the file at `from` into the path `to`.
219−In `%clay`, `|mv` is just a shorthand for `|cp` then `|rm`. The `|rm`
229+In `%clay`, `|mv` is just a shorthand for `|cp` then `|rm`. The `|rm`
220doesn't happen unless the `|cp` succeeds.
230doesn't happen unless the `|cp` succeeds.
222### Generators
232### Generators
234+<h3 class="first child">
224−<h3 class="first child"><code>+cat path [path ...]</code></h3>
235+<code>+cat path [path ...]</code>
226−Similar to Unix `cat`. `+cat` takes one or more `path`s, and prints
238+Similar to Unix `cat`. `+cat` takes one or more `path`s, and prints
227their contents.
239their contents.
229### `+ls path`
241### `+ls path`