X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;ds=inline;f=doc%2Fthreads.texi;h=dae47bb908a2fb87430c114e39efe15246e00c1f;hb=4eebaacd20c4d3bcc440751acdb8149ff9e56c11;hp=0b6bd701ff70acb6859c264959506acf8b14ae9a;hpb=58b094e0efe0b5744c6f33c565f7272e1c50992f;p=pintos-anon

diff --git a/doc/threads.texi b/doc/threads.texi
index 0b6bd70..dae47bb 100644
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -380,11 +380,36 @@ Problems 1-3 and 1-4 won't be needed for later projects.
 @end itemize
 
 @item
-Problem 1-4 (MLFQS) builds on the features you
-implement in Problem 1-3.  To avoid unnecessary code duplication, it
-would be a good idea to divide up the work among your team members
-such that you have Problem 1-3 fully working before you begin to tackle
-Problem 1-4.
+Problem 1-4 (MLFQS) builds on the features you implement in Problem
+1-3.  You should have Problem 1-3 fully working before you begin to
+tackle Problem 1-4.
+
+@item
+In the past, many groups divided the assignment into pieces, then each
+group member worked on his or her piece until just before the
+deadline, at which time the group reconvened to combine their code and
+submit.  @strong{This is a bad idea.  We do not recommend this
+approach.}  Groups that do this often find that two changes conflict
+with each other, requiring lots of last-minute debugging.  Some groups
+who have done this have turned in code that did not even successfully
+boot.
+
+Instead, we recommend integrating your team's changes early and often,
+using a source code control system such as CVS (@pxref{CVS}) or a
+group collaboration site such as SourceForge (@pxref{SourceForge}).
+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,
+when a change introduces a bug, drop back to working versions of code.
+
+@item
+You should expect to run into bugs that you simply don't understand
+while working on this and subsequent projects.  When you do, go back
+and reread the appendix on debugging tools, which is filled with
+useful debugging tips that should help you to get back up to speed
+(@pxref{Debugging Tools}).  Be sure to read the section on backtraces
+(@pxref{Backtraces}), which will help you to get the most out of every
+kernel panic or assertion failure.
 @end itemize
 
 @node Problem 1-1 Alarm Clock