Author's homepage

Disclaimer

This is how I do stuff. Other people use different methods. This isn't an introduction to CVS, or an introduction on how to do changes to the OpenBSD trees. Really. Ask the main developers for help if you don't know how to.

Prerequisites: Making a paranoid copy

First, I took a checkout of the tree that should make stupid blunders hard.

% su
# mkdir -p /var/master-sources
# cd /var/master-sources # Not a good directory but that's where I had some space at the time..
# cvs co src ports www XF4
# find . -type f | xargs chmod 444
# find . -name "Root" | xargs perl -pi -e 's|.*|ILLEGAL CVSROOT, CHECK YOUR CHANGES BEFORE COMMITTING! Oh, and did I mention you should check the changes before commiting?|'

The Steps

  1. Making a change and diffing it

    I make the change against a copy that isn't linked to master sources with a commit access. I use cvsup and a local /cvs directory for that purpose.

    I do a cvs diff after making the changes.

    % cd /usr/<tree>/<subdir>
% vim <file>
% cvs diff -u <file> > <file>.patch

    Oh, and here's my cvsrc.

  2. Testing everything applicable

    For ports, I try to do at least a (possibly flavored) 

    % make -i uninstall
% make clean install uninstall

    For www, I try at least 

    % netscape <file>
% opera <file>
% konqueror <file>
% w3m <file>
% links <file>
% lynx <file>

    For src and XF4, one should probably do a full release. For this, I use this Makefile.

  3. Writing a log message

    % cp <file>.patch $<file>.log
% vim <file>.log

    Next, I comment every change I've done. I try to be wordy. I also add 'ok maintainer@' ready there so that I won't forget it.

  4. Asking for comments

    Next, I write a mail to a developer - a maintainer for this area in the tree. I use a seperate shell account on another ISP to handle all my private mail: 

    % scp <file>.patch <file>.log saitti:
% mutt

    Then I mail the maintainer(s) with a short text 'ok?', and insert the files to the message. (That's right, I don't attach them; this way I can be sure that the person has minimum possibility to ignore it.)

  5. Making changes

    Often, I get comments back that encourage or advise me to improve my change in some way. I start again at level 1. I repeat as long as needed.

  6. Patching files

    I use the same patch I last sent to the maintainer. This way I can be sure the commit I'm making is the same that got ok'd.

    % cd /var/master-sources/<tree>/<subdir>
# su
# patch -p0 < <file>.patch

  7. Checking the diff again

    Note: I don't put the CVSROOT in my environment for any other occasions. I just use it for the final diff and commit.

    % cvs -d$TRUECVSROOT diff <file>

  8. Drinking some coffee

    I reread the diff. I blink my eyes. I drink coffee, pepsi, Red Bull, whatever. I blink again.

  9. Faking with cvs -n

    The -n flag does not change any file. I try the commit with it first. Warning! -n flag is used left of the 'commit' command.

    % cvs -n com <file>
  10. Commiting

    Finally, I commit: 

    % cvs -d$TURECVSROOT 1) com <file>

    And now, I can just 

    :r <file>.log

    I read it once more, and

    :q!
a

    (a is for a)bort) if I feel unsure about something.







1) the "typo" is there to make sure you read the whole document and don't jump into conclusions