From: Godmar Back Date: Wed, 9 Jan 2008 19:48:05 +0000 (+0000) Subject: - moved all instructions that related to local CVS/group setup in localcvsinstruction... X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8bc47e15da36b072924f8281688ea92935ae1c18;p=pintos-anon - moved all instructions that related to local CVS/group setup in localcvsinstructions.texi - added variables recommendsourceforge, recommendvnc, and recommendcygwin to include/exclude recommendations to use sourceforge, VNC, and Cygwin, resp. --- diff --git a/doc/devel.texi b/doc/devel.texi index d5439ed..ea024c1 100644 --- a/doc/devel.texi +++ b/doc/devel.texi @@ -4,11 +4,14 @@ 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 +70,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 +89,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 +99,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{} + diff --git a/doc/localcvsinstructions.texi b/doc/localcvsinstructions.texi new file mode 100644 index 0000000..467bf52 --- /dev/null +++ b/doc/localcvsinstructions.texi @@ -0,0 +1,172 @@ +@c +@c Instructions on how to set up a group environment, permissions, +@c CVS repository, dealing with local locking issues etc. +@c +@c While some of the discussion may apply to more than one environment, +@c no attempt was made to untangle and split the discussion. +@c + +@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. diff --git a/doc/localsettings.texi b/doc/localsettings.texi index 6a3dc3e..e8bb45b 100644 --- a/doc/localsettings.texi +++ b/doc/localsettings.texi @@ -5,6 +5,10 @@ @set localpintoshttppath http://@/www.stanford.edu/@/class/@/cs140/@/pintos/@/pintos.@/tar.gz @set localpintosbindir /usr/class/cs140/`uname -m`/bin +@set recommendsourceforge +@set recommendvnc +@clear recommendcygwin + @macro localmachines{} The CS 140 ``officially supported'' Pintos development machines are the machines in Sweet Hall managed by Stanford ITSS, as described on @@ -71,3 +75,6 @@ reviewing that document. We expect code at the ``Peer-Review Quality'' level described there. @end macro +@macro localdevelopmenttools{} +@c Descriptions of additional, local development tools can be inserted here +@end macro