Switch docs to use Git instead of CVS by default

Also a few minor changes to localsettings.texi.

diff --git a/doc/devel.texi b/doc/devel.texi
index f7f00a726e2f263df312df2bc14d28428a7c8789..588f1857474ca5b109d4f63b543b968c64ff2e36 100644 (file)
--- a/doc/devel.texi
+++ b/doc/devel.texi
@@ -6,7 +6,12 @@ Here are some tools that you might find useful while developing code.
 @menu
 * Tags::
 * cscope::
+@ifset recommendcvs
 * CVS::
+@end ifset
+@ifset recommendgit
+* Git::
+@end ifset
 @ifset recommendvnc
 * VNC::
 @end ifset 
@@ -58,6 +63,20 @@ Emacs and some versions of @command{vi} have their own interfaces to
 visit @url{http://cscope.sourceforge.net, the @command{cscope} home
 page}.
 
+@ifset recommendgit
+@node Git
+@section Git
+
+It's crucial that you use a source code control system to manage your
+Pintos code. This will allow you to keep track of your changes
+and coordinate changes made by different people in the project. For this
+class we recommend that you use Git; if you followed the instructions on
+getting started, a Git repository will already have been created for you.
+If you don't already know how to use Git, we recommend that you read
+the @uref{http://git-scm.com/book, , Pro Git} book online.
+@end ifset
+
+@ifset recommendcvs
 @node CVS
 @section CVS
 
@@ -78,6 +97,7 @@ For more information, visit the @uref{https://www.cvshome.org/, , CVS
 home page}.
 
 @include localcvsinstructions.texi
+@end ifset
 
 @ifset recommendvnc
 @node VNC

diff --git a/doc/intro.texi b/doc/intro.texi
index 8e935bb5a57d9456546f7d7112215972d30ca9c3..5372f74bb6a266d2787ec1c45264823996bd2ae7 100644 (file)
--- a/doc/intro.texi
+++ b/doc/intro.texi
@@ -68,11 +68,8 @@ environment.
 Now you can extract the source for Pintos into a directory named
 @file{pintos/src}, by executing
 @example
-zcat @value{localpintostarpath} | tar x
+git clone @value{gitrepo}
 @end example
-Alternatively, fetch
-@uref{@value{localpintoshttppath}}
-and extract it in a similar way.
 
 Let's take a look at what's inside.  Here's the directory structure
 that you should see in @file{pintos/src}:

diff --git a/doc/localsettings.texi b/doc/localsettings.texi
index 3e41b8b1f7a4f0c0f3d44eadebc7d02a521a2c27..765076d291ae5ac004391f9b4fb4eb86fb0a689f 100644 (file)
--- a/doc/localsettings.texi
+++ b/doc/localsettings.texi
@@ -1,17 +1,17 @@
 @c Local settings
 
-@set localpintostarpath /usr/class/cs140/pintos/pintos.tar.gz
+@set gitrepo file:///usr/class/cs140/winter13/pintos/.git
 @set localpintoshttppath http://@/www.stanford.edu/@/class/@/cs140/@/pintos/@/pintos.@/tar.gz
 @set localpintosbindir /usr/class/cs140/`uname -m`/bin
 
 @set recommendvnc
+@set recommendgit
 @clear recommendcygwin
+@clear recommendcvs
 
 @macro localmachines{}
 The CS 140 ``officially supported'' Pintos development machines are
-the machines in Sweet Hall managed by Stanford ITSS, as described on
-the @uref{http://www.stanford.edu/services/cluster/environs/sweet/, ,
-ITSS webpage}.  You may use the Solaris or Linux machines.
+those in the myth, corn, and cardinal clusters.
 @end macro
 
 @macro localpathsetup{}
@@ -31,14 +31,6 @@ you log in.
 @end macro
 
 @macro localcrossbuild{}
-Watch the commands executed during the build.  On the Linux machines,
-the ordinary system tools are used.  On a SPARC machine, special build
-tools are used, whose names begin with @samp{i386-elf-}, e.g.@:
-@code{i386-elf-gcc}, @code{i386-elf-ld}.  These are ``cross-compiler''
-tools.  That is, the build is running on a SPARC machine (called the
-@dfn{host}), but the result will run on a simulated 80@var{x}86 machine
-(called the @dfn{target}).  The @samp{i386-elf-@var{program}} tools are
-specially built for this configuration.
 @end macro
 
 @macro localhonorcodepolicy{}
@@ -56,7 +48,7 @@ inspired your own in your design documentation.
 
 @macro localcvspolicy{}
 Instead, we recommend integrating your team's changes early and often,
-using a source code control system such as CVS (@pxref{CVS}).
+using a source code control system such as Git (@pxref{Git}).
 This is less likely to produce surprises, because everyone can see
 everyone else's code as it is written, instead of just when it is
 finished.  These systems also make it possible to review changes and,