Assignment 4. Change management
Useful pointers
- Michael Johnson, Diff,
Patch, and Friends, Linux Journal 28 (1996-08)
- Larry Ayers,
Patch for Beginners, Linux Gazette 32 (1998-09)
- Greg White, CVS Cheat-sheet (2005-03-28)
- David MacKenzie, Paul Eggert, and Richard Stallman,
Comparing
and merging files, version 2.8.1 (2002-04-05)
- Karl Fogel and Moshe Bar, Open Source Development with CVS, 3rd
edition (2003). Especially see chapter 2, "An Overview of CVS".
- Derek Price et al,
CVS
FAQ
- Per Cederqvist, Version
Management with CVS, release 1.12.13 (2005-10-03)
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:
- Download coreutils 5.2.1.
- Use the patch command to apply the patch mentioned
above.
- Record any problems you had in applying the patch.
- Fix any problems with the patch by hand, by using your favorite
text editor.
- 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 *
- 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.
- Import coreutils 5.2.1 into a new CVS repository of your own, as a
vendor
branch.
- 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.
- Verify that the changed version works, as above.
- Use cvs diff to generate the backported patch into a
file hw4.patch.
- Use a text editor to make the ChangeLog entries have the same
format as the original patch.
- 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).
Submit
Submit the following files.
- The files lab4.txt and lab4.diff as
described in the lab.
- The file hw4.patch as described in the homework.
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 Paul Eggert.
See copying rules.
$Id: assign4.html,v 1.6 2007/01/30 07:27:35 eggert Exp $