mcs/gmcs/README.merging

   1 To preserve history and to make it easier to undo changes, I usually
   2 merge individual changes.  This may sound difficult, but in fact it's not.
   3 The most important thing is to get a feeling for it and find a good
   4 balance between merging time and testing time.
   5
   6 Here's how I usually do it:
   7
   8 * pick a day where you are not too busy doing other stuff
   9
  10 * Look at the current merging status:
  11
  12   $ cd mcs/gmcs
  13   $ svn propget gmcs .
  14
  15   For the rest of this document, let's assume everything till r49341 is
  16   merged.
  17
  18 * Do a
  19
  20   $ svn log -r 49341:HEAD .. /mcs/ | a2ps
  21
  22   to print the SVN history.
  23
  24   Read over it, completely to till the end.  Look out especially for
  25   reverted changes.  If you encounter a reverted change, take a note
  26   at the revision which introduced the change - so you know later on
  27   that you don't have to merge that revision.
  28
  29 * Make sure you have a working tree `make bootstrap-world' works; don't
  30   touch that tree during the merging.  I usually do the merging in a
  31   separate tree, so I can continue working while the tests are running.
  32
  33 * After that, I start merging like this:
  34
  35   $ cd /work/rohan/mono/mcs
  36   $ cp -a gmcs gmcs.0           # make a copy of the working version
  37   $ cd gmcs
  38   $ svn merge -r 49341:49488 ../mcs/
  39   $ make                        # make sure it compiles; this can save
  40                                   you a lot of time later !
  41   $ cp -a . ../gmcs.49489       # make a copy
  42   $ svn merge -r 49488:49497
  43
  44   ....
  45
  46   You usually get conflicts in the ChangeLog; make sure to resolve them
  47   before going on.
  48
  49 * If there are several consecutive small changes from the same person,
  50   I usually merge them at once.  The same applies if someone made trivial
  51   changes like fixing a typo; I include them in the previous revision.
  52
  53 * If the next revision contains a larger or structural change (patches
  54   from Marek and Hari are a good example), I stop the merging and run
  55   the tests:
  56
  57   $ make -C /work/rohan/mono bootstrap-world > logfile 2>&1 &
  58   $ tail -f logfile
  59
  60   Then I go work on something else.  It usually takes about 20-30 minutes
  61   for the tests to run.
  62
  63 * If the tests succeeded, I commit all the previous revisions:
  64
  65   $ cd ../gmcs.49488
  66   $ mv ChangeLog ChangeLog.new ; svn up ; mv ChangeLog.new ChangeLog
  67   $ svn ci -m "**** Merged r49487-49488 from MCS ****"
  68   $ cd ../gmcs.49497
  69
  70   The `mv ChangeLog' is a small trick: SVN would otherwise mark the file
  71   as conflict.  The `svn up' is neccessary as it'd otherwise report a
  72   "working directory out of date" error.
  73
  74 * After that, I take a note on my paper that I merged everything till
  75   this revision and clean up:
  76
  77   $ cp /work/gondor/mono/mcs/gmcs
  78   $ rm -rf ../gmcs.*
  79   $ cp -a . ../gmcs.0
  80
  81 * When done, update the merging history:
  82
  83   svn propedit gmcs .
  84
  85 That's it, basically.
  86 Martin
  87