Assignment 4. Change management

Useful pointers

Laboratory: Backporting a change

As usual, keep a log in the file lab4.txt of what you do in the lab so that you can reproduce the results later. This should not merely be a transcript of what you typed: it should be more like a true lab notebook, in which you briefly note down what you did and what happened.

You're helping to maintain a large site that supports many naive GNU/Linux users. Every few days one of them asks you the frequently-asked question, "How do I remove files that start with a dash?" and you patiently answer it by point them to the coreutils FAQ. There must be a better way.

You search the Internet for ideas, and find a coreutils patch posted 2005-08-29 that addresses the issue by having the rm command suggest the answer to the frequently-asked question whenever the situation seems to warrant it.

That patch applies to CVS coreutils as of the date the patch was applied, but your site is using coreutils 5.2.1. You don't want to upgrade your site to a newer version of coreutils since that may cause other compatibility-issue problems. You just want coreutils 5.2.1 with the patch.

Backport the 2005-08-29 patch, as follows:

  1. Download coreutils 5.2.1.
  2. Use the patch command to apply the patch mentioned above.
  3. Record any problems you had in applying the patch.
  4. One of the problems you will have is that it won't compile! Try this patch and see if that helps.
  5. Fix any problems with the patch by hand, by using your favorite text editor.
  6. Build the resulting modified version of coreutils, and verify that it does the right thing with this scenario:
    mkdir test
    cd test
    touch ./-ooops a b c
    rm *
    
  7. Generate a tentative version of your patch by using diff with the -u option to compare the original version of rm.c with your modified version. Put this tentative patch into the file lab4.diff.

Homework: Verifying and publishing the backported change

You're happy with the backported patch that you prepared in your assignment, but now you'd like to publish this backported patch, in a form similar to that presented in the original patch, so that others can use it.

  1. Import coreutils 5.2.1 into a new CVS repository of your own, as a vendor branch.
  2. Install your change in the main branch of the CVS repository. This should affect at least the two files affected by the original patch, along with the ChangeLog file.
  3. Verify that the changed version works, as above.
  4. Use cvs diff to generate the backported patch into a file hw4.patch.
  5. Use a text editor to make the ChangeLog entries have the same format as the original patch.
  6. Use diff to verify that the command patch -p0 <hw4.patch, when applied to a vanilla coreutils 5.2.1 distribution, generates your modified version (not counting the ChangeLog changes).

At your option, you may use Git rather than CVS. It's newer and much nicer in many ways, but isn't documented as well. See "Useful pointers" above.

Submit

Submit the following files.

All files should be ASCII text files, with no carriage returns, and with no more than 100 columns per line. The shell command:

expand lab4.txt lab4.diff hw4.patch | awk '/\r/ || 100 < length'

should output nothing.


© 2005, 2007, 2008 Paul Eggert. See copying rules.
$Id: assign4.html,v 1.9 2009/01/23 00:16:01 eggert Exp $