X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=8e6e38de64de1b93777a2e5f3770c094d321c612;hb=9cb684d97af902ab238b658d40b155cc33e2dcc7;hp=eb59d8a4267de1629c3f3d30037faab13c4d5a8b;hpb=b6e3e1c1e0bd9ccaa88bc4aff36b22b426132ba8;p=pintos-anon

diff --git a/doc/threads.texi b/doc/threads.texi
index eb59d8a..8e6e38d 100644
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -383,6 +383,24 @@ Problems 1-3 and 1-4 won't be needed for later projects.
 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.
 @end itemize
 
 @node Problem 1-1 Alarm Clock