X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?p=pintos-anon;a=blobdiff_plain;f=doc%2Fdevel.texi;h=eae54d163956de002a61f1d78424326704c31509;hp=d5439ed7e926f0ba6300ae39b4c234ef02f62ae9;hb=5af653aea4f817d41de3d2ab3a9eeaec44016234;hpb=41c6d30ad899676a4362bc1a18fca3d7c3eb3c49 diff --git a/doc/devel.texi b/doc/devel.texi index d5439ed..eae54d1 100644 --- a/doc/devel.texi +++ b/doc/devel.texi @@ -4,11 +4,18 @@ Here are some tools that you might find useful while developing code. @menu -* Tags:: -* cscope:: -* CVS:: -* SourceForge:: -* VNC:: +* Tags:: +* cscope:: +* CVS:: +@ifset recommendsourceforge +* SourceForge:: +@end ifset +@ifset recommendvnc +* VNC:: +@end ifset +@ifset recommendcygwin +* Cygwin:: +@end ifset @end menu @node Tags @@ -67,178 +74,15 @@ as of some given day and time. The version control logs tell you who made changes and when. CVS is not the best version control system out there, but it's -free, it's fairly easy to use, and -it's already available on the Leland machines you're using for -the projects. +free, it's fairly easy to use, and it's already installed in most +Unix-like environments. For more information, visit the @uref{https://www.cvshome.org/, , CVS home page}. -@menu -* Setting Up CVS:: -* Using CVS:: -* CVS Locking:: -@end menu - -@node Setting Up CVS -@subsection Setting Up CVS - -To set up CVS for use with Pintos on the Leland machines, start by -choosing one group member as the keeper of the CVS repository. -Everyone in the group will be able to use the CVS repository, but the -keeper will actually create the repository, keep its files in his or -her home directory, and maintain permissions for its contents. - -The keeper has to perform several steps to set up the repository. -First, create a new AFS group for the repository by executing -@samp{pts creategroup @var{keeper}:pintos-cvs}, where @var{keeper} is -the keeper's Leland username. Then, add each group member to the new -group by repeatedly using the command @samp{pts adduser -user -@var{username} -group @var{keeper}:pintos-cvs}, where @var{username} -is the name of a group member. After the group is created and its -members added, @samp{pts membership @var{keeper}:pintos-cvs} should -report that each group member is a member of the -@samp{@var{keeper}:pintos-cvs} group. - -The keeper now creates the repository directory and gives the group -members access to it. We will assume that the repository will be in a -directory called @file{cvs} in the keeper's home directory. First -create this directory with @samp{mkdir $HOME/cvs}, then give group -members access to it with @samp{fs setacl -dir $HOME/cvs -acl -@var{keeper}:pintos-cvs write}. Group members also need to be able to -look up the @file{cvs} directory in the keeper's home directory, which -can be enabled via @samp{fs setacl -dir $HOME -acl -@var{keeper}:pintos-cvs l} (that's letter ``ell,'' not digit -``one.'').@footnote{This command will allow group members to list the -files in your home directory, but not read or write them. It should not -create a security risk unless the names of files in your home directory -are secret.} - -Now initialize the repository. -To initialize the repository, execute @samp{cvs -d $HOME/cvs init}. - -Finally, import the Pintos sources into the newly initialized -repository. If you have an existing set of Pintos sources you want to -add to the repository, @samp{cd} to its @samp{pintos} directory now. -Otherwise, to import the base Pintos source tree, @samp{cd} to -@file{/usr/class/cs140/pintos/pintos} (note the doubled -@samp{pintos}). After changing the current directory, execute this -command: -@example -cvs -d $HOME/cvs import -m "Imported sources" pintos foobar start -@end example - -Here is a summary of the commands you have now executed: - -@example -pts creategroup @var{keeper}:pintos-cvs -pts adduser -user @var{username} -group @var{keeper}:pintos-cvs -mkdir $HOME/cvs -fs setacl -dir $HOME/cvs -acl @var{keeper}:pintos-cvs write -fs setacl -dir $HOME -acl @var{keeper}:pintos-cvs l -cvs -d $HOME/cvs init -cd /usr/class/cs140/pintos/pintos -cvs -d $HOME/cvs import -m "Imported sources" pintos foobar start -@end example - -The repository is now ready for use by any group member, as described -below. Keep in mind that the repository should only be accessed -using CVS commands---it is not generally useful to examine them by -hand, and you should definitely not modify them yourself. - -@node Using CVS -@subsection Using CVS - -To use CVS, start by check out a working copy of the contents of the -CVS repository into a directory named @file{@var{dir}}. To do so, execute -@samp{cvs -d ~@var{keeper}/cvs checkout -d @var{dir} pintos}, where -@var{keeper} is the CVS keeper's Leland username. - -(If this fails due to some kind of permission problem, then run -@command{aklog} and try again. If it still doesn't work, log out and -back in. If that still doesn't fix the problem, the CVS repository may -not be initialized properly.) - -At this point, you can modify any of the files in the working copy. -You can see the changes you've made with @samp{cvs diff -u}. If you -want to commit these changes back to the repository, making them -visible to the other group members, you can use the CVS commit -command. Within the @file{pintos} directory, execute @samp{cvs -commit}. This will figure out the files that have been changed and -fire up a text editor for you to describe the changes. By default, -this editor is @file{vi}, but you can select a different editor by -setting the @env{CVSEDITOR} environment variable, e.g.@: with -@samp{setenv CVSEDITOR emacs} (add this line to your @file{.cvsrc} to -make it permanent). - -Suppose another group member has committed changes. You can see the -changes committed to the repository since the time you checked it out -(or updated from it) with @samp{cvs diff -u -r BASE -r HEAD}. You can -merge those change into your working copy using @samp{cvs update}. If -any of your local changes conflict with the committed changes, the CVS -command output should tell you. In that case, edit the files that -contain conflicts, looking for @samp{<<<} and @samp{>>>} that denote -the conflicts, and fix the problem. - -You can view the history of @var{file} in your working directory, -including the log messages, with @samp{cvs log @var{file}}. - -You can give a particular set of file versions a name called a -@dfn{tag}. First @samp{cd} to the root of the working copy, then -execute @samp{cvs tag @var{name}}. It's best to have no local changes -in the working copy when you do this, because the tag will not include -uncommitted changes. To recover the tagged repository later, use the -@samp{checkout} command in the form @samp{cvs -d ~@var{keeper}/cvs -checkout -r @var{tag} -d @var{dir} pintos}, where @var{keeper} is the -username of the CVS keeper and @var{dir} is the directory to put the -tagged repository into. - -If you add a new file to the source tree, you'll need to add it to the -repository with @samp{cvs add @var{file}}. This command does not have -lasting effect until the file is committed later with @samp{cvs -commit}. - -To remove a file from the source tree, first remove it from the file -system with @command{rm}, then tell CVS with @samp{cvs remove -@var{file}}. Again, only @samp{cvs commit} will make the change -permanent. - -To discard your local changes for a given file, without committing -them, use @samp{cvs update -C @var{file}}. - -To check out a version of your repository as of a particular date, use -the command @samp{cvs -d ~@var{keeper}/cvs checkout -D '@var{date}' -d -@var{dir} pintos}, where @var{keeper} is the username of the CVS -keeper and @var{dir} is the directory to put the tagged repository -into.. A typical format for @var{date} is @samp{YYYY-MM-DD HH:MM}, -but CVS accepts several formats, even something like @samp{1 hour -ago}. - -For more information, visit the @uref{https://www.cvshome.org/, , CVS -home page}. - -@node CVS Locking -@subsection CVS Locking - -You might occasionally see a message like this while using CVS: - -@example -waiting for blp's lock in /afs/ir/users/b/l/blp/cvs -@end example - -This normally means that more than one user is accessing the repository -at the same time. CVS should automatically retry after 30 seconds, at -which time the operation should normally be able to continue. - -If you encounter a long wait for a lock, of more than a minute or so, it -may indicate that a CVS command did not complete properly and failed to -remove its locks. If you think that this is the case, ask the user in -question about it. If it appears that an operation did go awry, then -you (or the named user) can delete files whose names start with -@file{#cvs.rfl}, @file{#cvs.wfl}, or @file{#cvs.lock} in the directory -mentioned in the message. Doing so should allow your operation to -proceed. Do not delete or modify other files. +@include localcvsinstructions.texi +@ifset recommendsourceforge @node SourceForge @section SourceForge @@ -249,7 +93,9 @@ You can use it to store files, track bugs, and post notes about development progress. You can set up your own project in SourceForge at @uref{http://sourceforge.net, , sourceforge.net}. +@end ifset +@ifset recommendvnc @node VNC @section VNC @@ -257,6 +103,22 @@ VNC stands for Virtual Network Computing. It is, in essence, a remote display system which allows you to view a computing ``desktop'' environment not only on the machine where it is running, but from anywhere on the Internet and from a wide variety of machine -architectures. It is already installed on the Leland machines. For -more information, look at the @uref{http://www.realvnc.com/, , VNC +architectures. It is already installed on the lab machines. +For more information, look at the @uref{http://www.realvnc.com/, , VNC Home Page}. +@end ifset + +@ifset recommendcygwin +@node Cygwin +@section Cygwin + +@uref{http://cygwin.com/, ,Cygwin} provides a Linux-compatible environment +for Windows. It includes ssh client and an X11 server, Cygwin/X. If your +primary work environment is Windows, you will find Cygwin/X extremely +useful for these projects. Install Cygwin/X, then start the X server +and open a new xterm. The X11 server also allows you to run pintos while +displaying the bochs- or qemu-emulated console on your Windows desktop. +@end ifset + +@localdevelopmenttools{} +