Autogenerated HTML docs for v1.5.6.2-212-g08b5

author: Junio C Hamano <junio@hera.kernel.org> 2008-07-06 05:20:31 +0000
committer: Junio C Hamano <junio@hera.kernel.org> 2008-07-06 05:20:31 +0000
commit: ba4b9286c25f18c7ebbb809ee5732a7810377ab6 (patch)
tree: 390507328a7564b65dc803683c34235700b97409 /gitcvs-migration.html
parent: 05bf9c54a827e48b2b576488f5170a3490b5180e (diff)
download: git-htmldocs-ba4b9286c25f18c7ebbb809ee5732a7810377ab6.tar.gz
1 files changed, 131 insertions, 79 deletions
diff --git a/gitcvs-migration.html b/gitcvs-migration.html
index 7c914eb0e..758fe9305 100644
--- a/gitcvs-migration.html
+++ b/gitcvs-migration.html
@@ -3,7 +3,7 @@
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-<meta name="generator" content="AsciiDoc 7.0.2" />
+<meta name="generator" content="AsciiDoc 8.2.5" />
 <style type="text/css">
 /* Debug borders */
 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
@@ -16,8 +16,13 @@ body {
   margin: 1em 5% 1em 5%;
 }
 
-a { color: blue; }
-a:visited { color: fuchsia; }
+a {
+  color: blue;
+  text-decoration: underline;
+}
+a:visited {
+  color: fuchsia;
+}
 
 em {
   font-style: italic;
@@ -39,13 +44,18 @@ h1, h2, h3, h4, h5, h6 {
   line-height: 1.3;
 }
 
-h1 {
+h1, h2, h3 {
   border-bottom: 2px solid silver;
 }
 h2 {
-  border-bottom: 2px solid silver;
   padding-top: 0.5em;
 }
+h3 {
+  float: left;
+}
+h3 + * {
+  clear: left;
+}
 
 div.sectionbody {
   font-family: serif;
@@ -70,7 +80,7 @@ span#author {
   color: #527bbd;
   font-family: sans-serif;
   font-weight: bold;
-  font-size: 1.2em;
+  font-size: 1.1em;
 }
 span#email {
 }
@@ -139,6 +149,9 @@ div.sidebarblock > div.content {
   padding: 0.5em;
 }
 
+div.listingblock {
+  margin-right: 0%;
+}
 div.listingblock > div.content {
   border: 1px solid silver;
   background: #f4f4f4;
@@ -148,9 +161,13 @@ div.listingblock > div.content {
 div.quoteblock > div.content {
   padding-left: 2.0em;
 }
-div.quoteblock .attribution {
+
+div.attribution {
   text-align: right;
 }
+div.verseblock + div.attribution {
+  text-align: left;
+}
 
 div.admonitionblock .icon {
   vertical-align: top;
@@ -194,13 +211,12 @@ dd > *:first-child {
 ul, ol {
     list-style-position: outside;
 }
-ol.olist2 {
+div.olist2 ol {
   list-style-type: lower-alpha;
 }
 
 div.tableblock > table {
-  border-color: #527bbd;
-  border-width: 3px;
+  border: 3px solid #527bbd;
 }
 thead {
   font-family: sans-serif;
@@ -214,6 +230,9 @@ div.hlist {
   margin-top: 0.8em;
   margin-bottom: 0.8em;
 }
+div.hlist td {
+  padding-bottom: 5px;
+}
 td.hlist1 {
   vertical-align: top;
   font-style: italic;
@@ -226,7 +245,33 @@ td.hlist2 {
 @media print {
   div#footer-badges { display: none; }
 }
-include::./stylesheets/xhtml11-manpage.css[]
+
+div#toctitle {
+  color: #527bbd;
+  font-family: sans-serif;
+  font-size: 1.1em;
+  font-weight: bold;
+  margin-top: 1.0em;
+  margin-bottom: 0.1em;
+}
+
+div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+  margin-top: 0;
+  margin-bottom: 0;
+}
+div.toclevel2 {
+  margin-left: 2em;
+  font-size: 0.9em;
+}
+div.toclevel3 {
+  margin-left: 4em;
+  font-size: 0.9em;
+}
+div.toclevel4 {
+  margin-left: 6em;
+  font-size: 0.9em;
+}
+include1::./stylesheets/xhtml11-manpage.css[]
 /* Workarounds for IE6's broken and incomplete CSS2. */
 
 div.sidebar-content {
@@ -255,6 +300,9 @@ div.exampleblock-content {
   border-left: 2px solid silver;
   padding-left: 0.5em;
 }
+
+/* IE6 sets dynamically generated links as visited. */
+div#toc a:visited { color: blue; }
 </style>
 <title>gitcvs-migration(7)</title>
 </head>
@@ -272,81 +320,81 @@ gitcvs-migration(7) Manual Page
 </div>
 <h2>SYNOPSIS</h2>
 <div class="sectionbody">
-<p>git cvsimport *</p>
+<div class="para"><p>git cvsimport *</p></div>
 </div>
-<h2>DESCRIPTION</h2>
+<h2 id="_description">DESCRIPTION</h2>
 <div class="sectionbody">
-<p>Git differs from CVS in that every working tree contains a repository with
+<div class="para"><p>Git differs from CVS in that every working tree contains a repository with
 a full copy of the project history, and no repository is inherently more
 important than any other.  However, you can emulate the CVS model by
 designating a single shared repository which people can synchronize with;
-this document explains how to do that.</p>
-<p>Some basic familiarity with git is required. Having gone through
+this document explains how to do that.</p></div>
+<div class="para"><p>Some basic familiarity with git is required. Having gone through
 <a href="gittutorial.html">gittutorial(7)</a> and
-<a href="gitglossary.html">gitglossary(7)</a> should be sufficient.</p>
+<a href="gitglossary.html">gitglossary(7)</a> should be sufficient.</p></div>
 </div>
-<h2>Developing against a shared repository</h2>
+<h2 id="_developing_against_a_shared_repository">Developing against a shared repository</h2>
 <div class="sectionbody">
-<p>Suppose a shared repository is set up in /pub/repo.git on the host
+<div class="para"><p>Suppose a shared repository is set up in /pub/repo.git on the host
 foo.com.  Then as an individual committer you can clone the shared
-repository over ssh with:</p>
+repository over ssh with:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git clone foo.com:/pub/repo.git/ my-project
 $ cd my-project</tt></pre>
 </div></div>
-<p>and hack away.  The equivalent of <tt>cvs update</tt> is</p>
+<div class="para"><p>and hack away.  The equivalent of <em>cvs update</em> is</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git pull origin</tt></pre>
 </div></div>
-<p>which merges in any work that others might have done since the clone
+<div class="para"><p>which merges in any work that others might have done since the clone
 operation.  If there are uncommitted changes in your working tree, commit
-them first before running git pull.</p>
+them first before running git pull.</p></div>
 <div class="admonitionblock">
 <table><tr>
 <td class="icon">
 <div class="title">Note</div>
 </td>
 <td class="content">
-<p>The <tt>pull</tt> command knows where to get updates from because of certain
-configuration variables that were set by the first <tt>git-clone</tt>
+<div class="para"><p>The <em>pull</em> command knows where to get updates from because of certain
+configuration variables that were set by the first <em>git-clone</em>
 command; see <tt>git config -l</tt> and the <a href="git-config.html">git-config(1)</a> man
-page for details.</p>
+page for details.</p></div>
 </td>
 </tr></table>
 </div>
-<p>You can update the shared repository with your changes by first committing
-your changes, and then using the <tt>git-push</tt> command:</p>
+<div class="para"><p>You can update the shared repository with your changes by first committing
+your changes, and then using the <em>git-push</em> command:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git push origin master</tt></pre>
 </div></div>
-<p>to "push" those commits to the shared repository.  If someone else has
-updated the repository more recently, <tt>git-push</tt>, like <tt>cvs commit</tt>, will
+<div class="para"><p>to "push" those commits to the shared repository.  If someone else has
+updated the repository more recently, <em>git-push</em>, like <em>cvs commit</em>, will
 complain, in which case you must pull any changes before attempting the
-push again.</p>
-<p>In the <tt>git-push</tt> command above we specify the name of the remote branch
-to update (<tt>master</tt>).  If we leave that out, <tt>git-push</tt> tries to update
+push again.</p></div>
+<div class="para"><p>In the <em>git-push</em> command above we specify the name of the remote branch
+to update (<tt>master</tt>).  If we leave that out, <em>git-push</em> tries to update
 any branches in the remote repository that have the same name as a branch
-in the local repository.  So the last <tt>push</tt> can be done with either of:</p>
+in the local repository.  So the last <em>push</em> can be done with either of:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git push origin
 $ git push foo.com:/pub/project.git/</tt></pre>
 </div></div>
-<p>as long as the shared repository does not have any branches
-other than <tt>master</tt>.</p>
+<div class="para"><p>as long as the shared repository does not have any branches
+other than <tt>master</tt>.</p></div>
 </div>
-<h2>Setting Up a Shared Repository</h2>
+<h2 id="_setting_up_a_shared_repository">Setting Up a Shared Repository</h2>
 <div class="sectionbody">
-<p>We assume you have already created a git repository for your project,
+<div class="para"><p>We assume you have already created a git repository for your project,
 possibly created from scratch or from a tarball (see
 <a href="gittutorial.html">gittutorial(7)</a>), or imported from an already existing CVS
-repository (see the next section).</p>
-<p>Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
+repository (see the next section).</p></div>
+<div class="para"><p>Assume your existing repo is at /home/alice/myproject.  Create a new "bare"
 repository (a repository without a working tree) and fetch your project into
-it:</p>
+it:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ mkdir /pub/my-repo.git
@@ -354,95 +402,99 @@ $ cd /pub/my-repo.git
 $ git --bare init --shared
 $ git --bare fetch /home/alice/myproject master:master</tt></pre>
 </div></div>
-<p>Next, give every team member read/write access to this repository.  One
+<div class="para"><p>Next, give every team member read/write access to this repository.  One
 easy way to do this is to give all the team members ssh access to the
 machine where the repository is hosted.  If you don't want to give them a
 full shell on the machine, there is a restricted shell which only allows
-users to do git pushes and pulls; see <a href="git-shell.html">git-shell(1)</a>.</p>
-<p>Put all the committers in the same group, and make the repository
-writable by that group:</p>
+users to do git pushes and pulls; see <a href="git-shell.html">git-shell(1)</a>.</p></div>
+<div class="para"><p>Put all the committers in the same group, and make the repository
+writable by that group:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ chgrp -R $group /pub/my-repo.git</tt></pre>
 </div></div>
-<p>Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.</p>
+<div class="para"><p>Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.</p></div>
 </div>
-<h2>Importing a CVS archive</h2>
+<h2 id="_importing_a_cvs_archive">Importing a CVS archive</h2>
 <div class="sectionbody">
-<p>First, install version 2.1 or higher of cvsps from
+<div class="para"><p>First, install version 2.1 or higher of cvsps from
 <a href="http://www.cobite.com/cvsps/">http://www.cobite.com/cvsps/</a> and make
 sure it is in your path.  Then cd to a checked out CVS working directory
-of the project you are interested in and run <tt>git-cvsimport</tt>:</p>
+of the project you are interested in and run <em>git-cvsimport</em>:</p></div>
 <div class="listingblock">
 <div class="content">
 <pre><tt>$ git cvsimport -C &lt;destination&gt; &lt;module&gt;</tt></pre>
 </div></div>
-<p>This puts a git archive of the named CVS module in the directory
-&lt;destination&gt;, which will be created if necessary.</p>
-<p>The import checks out from CVS every revision of every file.  Reportedly
+<div class="para"><p>This puts a git archive of the named CVS module in the directory
+&lt;destination&gt;, which will be created if necessary.</p></div>
+<div class="para"><p>The import checks out from CVS every revision of every file.  Reportedly
 cvsimport can average some twenty revisions per second, so for a
 medium-sized project this should not take more than a couple of minutes.
-Larger projects or remote repositories may take longer.</p>
-<p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
+Larger projects or remote repositories may take longer.</p></div>
+<div class="para"><p>The main trunk is stored in the git branch named <tt>origin</tt>, and additional
 CVS branches are stored in git branches with the same names.  The most
 recent version of the main trunk is also left checked out on the <tt>master</tt>
-branch, so you can start adding your own changes right away.</p>
-<p>The import is incremental, so if you call it again next month it will
+branch, so you can start adding your own changes right away.</p></div>
+<div class="para"><p>The import is incremental, so if you call it again next month it will
 fetch any CVS updates that have been made in the meantime.  For this to
 work, you must not modify the imported branches; instead, create new
 branches for your own changes, and merge in the imported branches as
-necessary.</p>
+necessary.</p></div>
+<div class="para"><p>If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Then treat the imported
+directory as another development clone for purposes of merging
+incremental imports.</p></div>
 </div>
-<h2>Advanced Shared Repository Management</h2>
+<h2 id="_advanced_shared_repository_management">Advanced Shared Repository Management</h2>
 <div class="sectionbody">
-<p>Git allows you to specify scripts called "hooks" to be run at certain
+<div class="para"><p>Git allows you to specify scripts called "hooks" to be run at certain
 points.  You can use these, for example, to send all commits to the shared
-repository to a mailing list.  See <a href="githooks.html">githooks(5)</a>.</p>
-<p>You can enforce finer grained permissions using update hooks.  See
+repository to a mailing list.  See <a href="githooks.html">githooks(5)</a>.</p></div>
+<div class="para"><p>You can enforce finer grained permissions using update hooks.  See
 <a href="howto/update-hook-example.txt">Controlling access to branches using
-update hooks</a>.</p>
+update hooks</a>.</p></div>
 </div>
-<h2>Providing CVS Access to a git Repository</h2>
+<h2 id="_providing_cvs_access_to_a_git_repository">Providing CVS Access to a git Repository</h2>
 <div class="sectionbody">
-<p>It is also possible to provide true CVS access to a git repository, so
+<div class="para"><p>It is also possible to provide true CVS access to a git repository, so
 that developers can still use CVS; see <a href="git-cvsserver.html">git-cvsserver(1)</a> for
-details.</p>
+details.</p></div>
 </div>
-<h2>Alternative Development Models</h2>
+<h2 id="_alternative_development_models">Alternative Development Models</h2>
 <div class="sectionbody">
-<p>CVS users are accustomed to giving a group of developers commit access to
+<div class="para"><p>CVS users are accustomed to giving a group of developers commit access to
 a common repository.  As we've seen, this is also possible with git.
 However, the distributed nature of git allows other development models,
 and you may want to first consider whether one of them might be a better
-fit for your project.</p>
-<p>For example, you can choose a single person to maintain the project's
+fit for your project.</p></div>
+<div class="para"><p>For example, you can choose a single person to maintain the project's
 primary public repository.  Other developers then clone this repository
 and each work in their own clone.  When they have a series of changes that
 they're happy with, they ask the maintainer to pull from the branch
 containing the changes.  The maintainer reviews their changes and pulls
 them into the primary repository, which other developers pull from as
 necessary to stay coordinated.  The Linux kernel and other projects use
-variants of this model.</p>
-<p>With a small group, developers may just pull changes from each other's
-repositories without the need for a central maintainer.</p>
+variants of this model.</p></div>
+<div class="para"><p>With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.</p></div>
 </div>
-<h2>SEE ALSO</h2>
+<h2 id="_see_also">SEE ALSO</h2>
 <div class="sectionbody">
-<p><a href="gittutorial.html">gittutorial(7)</a>,
+<div class="para"><p><a href="gittutorial.html">gittutorial(7)</a>,
 <a href="gittutorial-2.html">gittutorial-2(7)</a>,
 <a href="gitcore-tutorial.html">gitcore-tutorial(7)</a>,
 <a href="gitglossary.html">gitglossary(7)</a>,
 <a href="everyday.html">Everyday Git</a>,
-<a href="user-manual.html">The Git User's Manual</a></p>
+<a href="user-manual.html">The Git User's Manual</a></p></div>
 </div>
-<h2>GIT</h2>
+<h2 id="_git">GIT</h2>
 <div class="sectionbody">
-<p>Part of the <a href="git.html">git(1)</a> suite.</p>
+<div class="para"><p>Part of the <a href="git.html">git(1)</a> suite.</p></div>
 </div>
 <div id="footer">
 <div id="footer-text">
-Last updated 02-Jul-2008 03:02:12 UTC
+Last updated 2008-07-06 05:17:12 UTC
 </div>
 </div>
 </body>
author	Junio C Hamano <junio@hera.kernel.org>	2008-07-06 05:20:31 +0000
committer	Junio C Hamano <junio@hera.kernel.org>	2008-07-06 05:20:31 +0000
commit	ba4b9286c25f18c7ebbb809ee5732a7810377ab6 (patch)
tree	390507328a7564b65dc803683c34235700b97409 /gitcvs-migration.html
parent	05bf9c54a827e48b2b576488f5170a3490b5180e (diff)
download	git-htmldocs-ba4b9286c25f18c7ebbb809ee5732a7810377ab6.tar.gz