Mention that aklog and/or logging out and back in may be necessary to
[pintos-anon] / doc / devel.texi
1 @node Development Tools, , Debugging Tools, Top
2 @appendix Development Tools
3
4 Here are some tools that you might find useful while developing code.
5
6 @menu
7 * Tags::                        
8 * CVS::                         
9 * SourceForge::                 
10 * VNC::                         
11 @end menu
12
13 @node Tags
14 @section Tags
15
16 Tags are an index to the functions and global variables declared in a
17 program.  Many editors, including Emacs and @command{vi}, can use
18 them.  The @file{Makefile} in @file{pintos/src} produces Emacs-style
19 tags with the command @code{make TAGS} or @command{vi}-style tags with
20 @code{make tags}.
21
22 In Emacs, use @kbd{M-.} to follow a tag in the current window,
23 @kbd{C-x 4 .} in a new window, or @kbd{C-x 5 .} in a new frame.  If
24 your cursor is on a symbol name for any of those commands, it becomes
25 the default target.  If a tag name has multiple definitions, @kbd{M-0
26 M-.} jumps to the next one.  To jump back to where you were before
27 you followed the last tag, use @kbd{M-*}.
28
29 @node CVS
30 @section CVS
31
32 CVS is a version-control system.  That is, you can use it to keep
33 track of multiple versions of files.  The idea is that you do some
34 work on your code and test it, then check it into the version-control
35 system.  If you decide that the work you've done since your last
36 check-in is no good, you can easily revert to the last checked-in
37 version.  Furthermore, you can retrieve any old version of your code
38 as of some given day and time.  The version control logs tell you who
39 made changes and when.
40
41 CVS is not the best version control system out there, but it's
42 free, it's fairly easy to use, and
43 it's already available on the Leland machines you're using for
44 the projects.
45
46 For more information, visit the @uref{https://www.cvshome.org/, , CVS
47 home page}.
48
49 @menu
50 * Setting Up CVS::              
51 * Using CVS::                   
52 @end menu
53
54 @node Setting Up CVS
55 @subsection Setting Up CVS
56
57 To set up CVS for use with Pintos on the Leland machines, start by
58 choosing one group member as the keeper of the CVS repository.
59 Everyone in the group will be able to use the CVS repository, but the
60 keeper will actually create the repository, keep its files in his or
61 her home directory, and maintain permissions for its contents.
62
63 The keeper has to perform several steps to set up the repository.
64 First, create a new AFS group for the repository by executing
65 @samp{pts creategroup @var{keeper}:pintos-cvs}, where @var{keeper} is
66 the keeper's Leland username.  Then, add each group member to the new
67 group by repeatedly using the command @samp{pts adduser -user
68 @var{username} -group @var{keeper}:pintos-cvs}, where @var{username}
69 is the name of a group member.  After the group is created and its
70 members added, @samp{pts membership @var{keeper}:pintos-cvs} should
71 report that each group member is a member of the
72 @samp{@var{keeper}:pintos-cvs} group.
73
74 The keeper now creates the repository directory and gives the group
75 members access to it.  We will assume that the repository will be in a
76 directory called @file{cvs} in the keeper's home directory.  First
77 create this directory with @samp{mkdir $HOME/cvs}, then give group
78 members access to it with @samp{fs setacl -dir $HOME/cvs -acl
79 @var{keeper}:pintos-cvs write}.  Group members also need to be able to
80 look up the @file{cvs} directory in the keeper's home directory, which
81 can be enabled via @samp{fs setacl -dir $HOME -acl
82 @var{keeper}:pintos-cvs l} (that's letter ``ell,'' not digit
83 ``one.'').@footnote{This command will allow group members to list the
84 files in your home directory, but not read or write them.  It should not
85 create a security risk unless the names of files in your home directory
86 are secret.}
87
88 Now initialize the repository.
89 To initialize the repository, execute @samp{cvs -d $HOME/cvs init}.
90
91 Finally, import the Pintos sources into the newly initialized
92 repository.  If you have an existing set of Pintos sources you want to
93 add to the repository, @samp{cd} to its @samp{pintos} directory now.
94 Otherwise, to import the base Pintos source tree, @samp{cd} to
95 @file{/usr/class/cs140/pintos/pintos} (note the doubled
96 @samp{pintos}).  After changing the current directory, execute this
97 command:
98 @example
99 cvs -d $HOME/cvs import -m "Imported sources" pintos foobar start
100 @end example
101
102 Here is a summary of the commands you have now executed:
103
104 @example
105 pts creategroup @var{keeper}:pintos-cvs
106 pts adduser -user @var{username} -group @var{keeper}:pintos-cvs
107 mkdir $HOME/cvs
108 fs setacl -dir $HOME/cvs -acl @var{keeper}:pintos-cvs write
109 fs setacl -dir $HOME -acl @var{keeper}:pintos-cvs l
110 cvs -d $HOME/cvs init
111 cd /usr/class/cs140/pintos/pintos
112 cvs -d $HOME/cvs import -m "Imported sources" pintos foobar start
113 @end example
114
115 The repository is now ready for use by any group member, as described
116 below.  Keep in mind that the repository should only be accessed
117 using CVS commands---it is not generally useful to examine them by
118 hand, and you should definitely not modify them yourself.
119
120 @node Using CVS
121 @subsection Using CVS
122
123 To use CVS, start by check out a working copy of the contents of the
124 CVS repository into a directory named @file{@var{dir}}.  To do so, execute
125 @samp{cvs -d ~@var{keeper}/cvs checkout -d @var{dir} pintos}, where
126 @var{keeper} is the CVS keeper's Leland username.
127
128 (If this fails due to some kind of permission problem, then run
129 @command{aklog} and try again.  If it still doesn't work, log out and
130 back in.  If that still doesn't fix the problem, the CVS repository may
131 not be initialized properly.)
132
133 At this point, you can modify any of the files in the working copy.
134 You can see the changes you've made with @samp{cvs diff -u}.  If you
135 want to commit these changes back to the repository, making them
136 visible to the other group members, you can use the CVS commit
137 command.  Within the @file{pintos} directory, execute @samp{cvs
138 commit}.  This will figure out the files that have been changed and
139 fire up a text editor for you to describe the changes.  By default,
140 this editor is @file{vi}, but you can select a different editor by
141 setting the @env{CVSEDITOR} environment variable, e.g.@: with
142 @samp{setenv CVSEDITOR emacs} (add this line to your @file{.cvsrc} to
143 make it permanent).
144
145 Suppose another group member has committed changes.  You can see the
146 changes committed to the repository since the time you checked it out
147 (or updated from it) with @samp{cvs diff -u -r BASE -r HEAD}.  You can
148 merge those change into your working copy using @samp{cvs update}.  If
149 any of your local changes conflict with the committed changes, the CVS
150 command output should tell you.  In that case, edit the files that
151 contain conflicts, looking for @samp{<<<} and @samp{>>>} that denote
152 the conflicts, and fix the problem.
153
154 You can view the history of @var{file} in your working directory,
155 including the log messages, with @samp{cvs log @var{file}}.
156
157 You can give a particular set of file versions a name called a
158 @dfn{tag}.  First @samp{cd} to the root of the working copy, then
159 execute @samp{cvs tag @var{name}}.  It's best to have no local changes
160 in the working copy when you do this, because the tag will not include
161 uncommitted changes.  To recover the tagged repository later, use the
162 @samp{checkout} command in the form @samp{cvs -d ~@var{keeper}/cvs
163 checkout -r @var{tag} -d @var{dir} pintos}, where @var{keeper} is the
164 username of the CVS keeper and @var{dir} is the directory to put the
165 tagged repository into.
166
167 If you add a new file to the source tree, you'll need to add it to the
168 repository with @samp{cvs add @var{file}}.  This command does not have
169 lasting effect until the file is committed later with @samp{cvs
170 commit}.
171
172 To remove a file from the source tree, first remove it from the file
173 system with @command{rm}, then tell CVS with @samp{cvs remove
174 @var{file}}.  Again, only @samp{cvs commit} will make the change
175 permanent.
176
177 To discard your local changes for a given file, without committing
178 them, use @samp{cvs update -C @var{file}}.
179
180 To check out a version of your repository as of a particular date, use
181 the command @samp{cvs -d ~@var{keeper}/cvs checkout -D '@var{date}' -d
182 @var{dir} pintos}, where @var{keeper} is the username of the CVS
183 keeper and @var{dir} is the directory to put the tagged repository
184 into..  A typical format for @var{date} is @samp{YYYY-MM-DD HH:MM},
185 but CVS accepts several formats, even something like @samp{1 hour
186 ago}.
187
188 For more information, visit the @uref{https://www.cvshome.org/, , CVS
189 home page}.
190
191 @node SourceForge
192 @section SourceForge
193
194 SourceForge is a web-based system for facilitating software
195 development.  It provides you with a version-control system (typically
196 CVS, as described above) and other tools for tracking your software.
197 You can use it to store files, track bugs, and post notes about
198 development progress.  You can set up your own
199 project in SourceForge at @uref{http://sourceforge.net, ,
200 sourceforge.net}.
201
202 @node VNC
203 @section VNC
204
205 VNC stands for Virtual Network Computing.  It is, in essence, a remote
206 display system which allows you to view a computing ``desktop''
207 environment not only on the machine where it is running, but from
208 anywhere on the Internet and from a wide variety of machine
209 architectures.  It is already installed on the Leland machines.  For
210 more information, look at the @uref{http://www.realvnc.com/, , VNC
211 Home Page}.