a9dcbf3ede 2008-12-16 kejoki: <h2>checkout</h2> a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: The <code>checkout</code> command is how a project version goes from a9dcbf3ede 2008-12-16 kejoki: the repository to the chosen project directory. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: Without going into detail about getting/opening a repository, once you a9dcbf3ede 2008-12-16 kejoki: have a repository and a place in which the repository has been a9dcbf3ede 2008-12-16 kejoki: opened, you can "check out" a "version" of the files which make up the a9dcbf3ede 2008-12-16 kejoki: repository at somewhen. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: The term "checkout" is traditional in source management systems, but a a9dcbf3ede 2008-12-16 kejoki: bit of an anachronism in a distributed system like <b>fossil</b>. a9dcbf3ede 2008-12-16 kejoki: "Checking out" a version of a project means getting all of the source a9dcbf3ede 2008-12-16 kejoki: artifacts out into the standard environment---currently the a9dcbf3ede 2008-12-16 kejoki: shell/file-system. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: Traditionally, the version is some "incrementing" code like a9dcbf3ede 2008-12-16 kejoki: v1.3.2rcQuink or f451 or something. In distributed SCM systems it's a9dcbf3ede 2008-12-16 kejoki: some absolutely unique identifier, usually the result of a one-way a9dcbf3ede 2008-12-16 kejoki: hash (SHA1, in fossil's case.) The <b>fossil</b> term for these is a9dcbf3ede 2008-12-16 kejoki: <em>artifact IDs</em>. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: <code>fossil checkout </code> <i>id</i> will check out the a9dcbf3ede 2008-12-16 kejoki: version corresponding to <i>id</i> into the source tree. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: <code>checkout</code> requires you to pick a precise version to put into a9dcbf3ede 2008-12-16 kejoki: the "on-disk" source tree, and leaves any edited files which are already a9dcbf3ede 2008-12-16 kejoki: in the tree intact. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: <code>update</code>, on the other hand, <em>merges</em> edits into the a9dcbf3ede 2008-12-16 kejoki: version you choose (if you choose one; you can default the version.) a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: Since a version is required, and <b>fossil</b>'s artifact IDs are a9dcbf3ede 2008-12-16 kejoki: fairly long, there are two good ways to refer to the version. You can a9dcbf3ede 2008-12-16 kejoki: use a unique proper prefix of the version (six or eight characters is a9dcbf3ede 2008-12-16 kejoki: more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | a9dcbf3ede 2008-12-16 kejoki: tag] your baselines and use the tags for checkouts, reverting, a9dcbf3ede 2008-12-16 kejoki: branching (tags are the best way to branch) and so forth. Both a9dcbf3ede 2008-12-16 kejoki: methods work throughout fossil. a9dcbf3ede 2008-12-16 kejoki: a9dcbf3ede 2008-12-16 kejoki: See also [./cmd_tag.wiki | fossil tag], a9dcbf3ede 2008-12-16 kejoki: [./cmd_revert.wiki | fossil revert], a9dcbf3ede 2008-12-16 kejoki: [./cmd_update.wiki | fossil update], a9dcbf3ede 2008-12-16 kejoki: [./cmd_push.wiki | fossil push], a9dcbf3ede 2008-12-16 kejoki: [./cmd_pull.wiki | fossil pull], c8b86eae78 2009-01-07 kejoki: [./cmd_clone.wiki | fossil clone], c8b86eae78 2009-01-07 kejoki: [./cmd_open.wiki | fossil open], c8b86eae78 2009-01-07 kejoki: [./cmd_close.wiki | fossil close], c8b86eae78 2009-01-07 kejoki: [./cmd_new.wiki | fossil new], a9dcbf3ede 2008-12-16 kejoki: [./reference.wiki | Reference]
File Annotation