Matthew Palmer writes ("Re: Centralized darcs"): > diff.gz archaeology should not be necessary.
I think this is the root of the key difference between the `like patch systems' people and the `hate patch systems' people. `Hate patch systems' people are those who can read code, and prefer programming and debuggint to doing archaelogy. They're people like me: my first approach to any bug I'm trying to fix (or change I'm trying to make) is to read and then edit the actual code. Only if I seem to be explicitly going against some other person's decision, or the whole thing seems crazy, will I try to find some archaeology or changelog or something in an effort to find out why it was done the crazy way. `Like patch systems' people are those who would prefer to do archaelogy to dealing with the actual code of a program written by someone else. These are people for whom the average level of clue in the world as represented by the history of the program and other people's patches exceeds their own ability to generate correct changes to the code. The resulting culture is one of `cargo culting' patches and `explanations' from one place to another, without really understanding them. When I work on Ubuntu packages I'm basically doing NMUs all the time and I have been forced into a completely insane workflow to deal with the mad patch systems: $ dpkg-source -x /export/mirror/.../program.dsc $ mkdir orig build $ rsync -a --delete --delete-excluded --exclude='*~' program orig/ $ rsync -a --delete --delete-excluded --exclude='*~' program build/ $ (cd build/program && debian/rules build && debian/rules binary) now edit build/program/stupid/long/path/src/program.c to make the bulk of my changes test the resulting program in the build tree if possible if I'm very lucky then I can edit program.c and $ make -C build/program/stupid/long/path/src program if I make a change but sometimes this is not possible and I have to resort to the process below $ diff -u build/program/stupid/long/path/src/program.c{~,} \ >program/debian/patches/999_my_new_patch now edit program/debian/patches/999_my_new_patch $ grep -R 888_some_existing_patch program this tells me whether 888_some_existing_patch needs to be added to a list of patches and if so I edit the list file also edit program/debian/changelog $ rsync -a --delete --delete-excluded --exclude='*~' program build/ $ (cd build/program && debian/rules build && debian/rules binary) not that this is a complete rebuild. I use ccache. $ really dpkg -i program.deb run test if test does not work, edit 999_my_new_patch and rebuild from scratch if test does work $ diff -ruN --exclude='*~' {orig/,}program >diff and send diff to bug system. This is incredibly clumsy but it has the virtue of being reliable and not requiring me to learn dmadpatch 0.37 as distributed in program 0.0.0.3 from 1999 and not having to deal with any bugs in patch systems etc. But, FFS! Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]