File: cmd_checkout.wiki

package info (click to toggle)
fossil 1%3A1.22.1%2Bdfsg-0.1
  • links: PTS
  • area: main
  • in suites: wheezy
  • size: 10,588 kB
  • sloc: ansic: 151,799; tcl: 10,291; sh: 4,413; makefile: 1,822; sql: 376
file content (50 lines) | stat: -rw-r--r-- 2,159 bytes parent folder | download | duplicates (2)
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
<h2>checkout</h2>

The <code>checkout</code> command is how a project version goes from
the repository to the chosen project directory.

Without going into detail about getting/opening a repository, once you
have a repository and a place in which the repository has been
opened, you can "check out" a "version" of the files which make up the
repository at somewhen.

The term "checkout" is traditional in source management systems, but a
bit of an anachronism in a distributed system like <b>fossil</b>.
"Checking out" a version of a project means getting all of the source
artifacts out into the standard environment---currently the
shell/file-system.

Traditionally, the version is some "incrementing" code like
v1.3.2rcQuink or f451 or something.  In distributed SCM systems it's
some absolutely unique identifier, usually the result of a one-way
hash (SHA1, in fossil's case.)  The <b>fossil</b> term for these is
<em>artifact IDs</em>.

<code>fossil&nbsp;checkout&nbsp;</code> <i>id</i> will check out the
version corresponding to <i>id</i> into the source tree.

<code>checkout</code> requires you to pick a precise version to put into
the "on-disk" source tree, and leaves any edited files which are already
in the tree intact.

<code>update</code>, on the other hand, <em>merges</em> edits into the
version you choose (if you choose one; you can default the version.)

Since a version is required, and <b>fossil</b>'s artifact IDs are
fairly long, there are two good ways to refer to the version.  You can
use a unique proper prefix of the version (six or eight characters is
more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki |
tag] your check-ins and use the tags for checkouts, reverting,
branching (tags are the best way to branch) and so forth.  Both
methods work throughout fossil.

See also [./cmd_tag.wiki | fossil tag],
[./cmd_revert.wiki | fossil revert],
[./cmd_update.wiki | fossil update],
[./cmd_push.wiki | fossil push],
[./cmd_pull.wiki | fossil pull],
[./cmd_clone.wiki | fossil clone],
[./cmd_open.wiki | fossil open],
[./cmd_close.wiki | fossil close],
[./cmd_new.wiki | fossil new],
[./reference.wiki | Reference]