So you use vi, linux-console-mode with six 80x60 screens, diff, patch,
ctags and
grep. Get a life and use emacs? No thanks. tried it. Was told that
it didn't have different modes for text-editing and text-entry, it was
better all-round. Had this wonderful thing called emerge, it could
solve all my problems of how to do, as Jeremy Allison described it from
over a year ago, "The MFH (tm)" - The Merge From Hell.
One Samba team member had already tried, and failed. To give you an
idea of the size of the task, the diff file between the stable Samba 2.0
tree and what is now the Samba TNG tree (The Next Generation), was 7
megabytes, and that was six months ago.
Two and a half years ago, the NT Domains for Unix project started, with
Paul Ashton's "Welcome to the SAMBA Domain" work. Since that time, when
the Samba source was only 150,000 or so lines of code, both the stable
Samba 2.0 production release tree and the TNG branch added an extra
50,000 lines of code - each. Fortunately, as it turns out, the
majority of the work in each branch was done in totally different
areas. The remaining areas are a nightmare to merge, and a pain in the
wrists to keep up-to-date on a daily basis.
So, what tools were available? Well... emerge. Except that means,
emacs. Eventually, I cornered someone, late on a Friday, for
instructions on how to use emerge. and emacs. Starting with one file,
it quickly became obvious that this simply wasn't going to cut it.
Press a, b, b, ab OOPS urr, Paul, how do I get out of this, to which the
response was, "'Bye, have a good weekend". to which my response was,
"Ctrl-c, argh, ctrl-d, ARGH, ctrl-z killall emacs".
If people laugh at me for using an editor that causes me to press
keystrokes such as mx:0d'x and yyP in notepad and pine, I will respond,
"and what's emerge, then?"
The very same Paul (who is going to kill me for this article, he really
doesn't want any more maintainer-request-email than he already gets) is
a fan of tcl and wish. In a former existence, instead of abandoning a
really large tcl script
in favour of a better, faster language, he wrote a code-optimiser for
tcl.
One of his tools that he has written in tcl is dirdiff. dirdiff, in a
previous incarnation, was able to show you one window with a comparative
diff of two or more directories, and you select one file from two of
thoes directories and it shows you the differences. If you liked one
file better than the other, you could select the "copy" menu to copy one
file over the other. Great for getting rid of all those pesky little
mods by another developer that you never really liked, anyway, their
code always got in the way of yours.
Anyway.
dirdiff-previous-life showed up the different lines in pretty colours.
To give you some idea, take a straight diff (diff file1.c file2.c). If
there's a <, display that bit in red. If there's a >, display that bit
in green. Insert red bits and green bits on-screen in amongst a bit of
context before and after, and voila, that's a dirdiff file display.
Then someone (I forget who) thought, you know, it would be really good
if i could clickety-click on da red bit or da green bit, and it goes
into one of the files...
*Fortunately*, Paul *also* needed something like this, as he needed to
merge three sets of pppd branches, and so rather than spend time
manually going back to diff and patch, he set about adding little
windows all the way down the left-hand-side of dirdiff's file display,
one for each line of the read bits and green bits. This means that if
the diffs are large, wish gets *really* pushed to the limit: that's a
lot of little windows. Tell you what, though: I don't care if it's
slow, it saves me that much time. And Paul's speed-optimisations help a
lot.
So, how do you use the new, improved, dirdiff? Well, at an xterm, you
type:
dirdiff ~/samba-tng/source/smbd ~/samba-main/source/smbd &
and up comes a windows with all the files that are common between the
two directories. select a file, and you get a dirdiff file-window, with
red bits and green bits, and on each red bit and green bit, there is a
series of buttons at the left. If you want to make a "change", you
select a button, with left-mouse. If you want to make a "group change",
use right-mouse and an entire group of buttons will select or deselect.
Having selected all your "changes" you wish to make, from the menu, you
then select the file to which all the "changes" are to be applied.
Behind the scenes, this creates a straight-diff patch file, which is
then applied to the file you selected. The result: only the "changes"
you selected are made to the file. Hit "Rediff", and wow, you have less
differences between the two files than when you started.
To give you some idea of the speed at which this can be done, I use
dirdiff by positioning the mouse cursor (IBM thinkpad nibble-thing) over
the left-hand-set-of-buttons, then rapidly press down-arrow on the
keyboard (about 3 or 4 times a second), interspersed with either
right-mouse or left-mouse clicks *without* changing the position of the
mouse. In this way, a 3,000-line file with... 50 to 100 sets of
diff-style modifications can be updated in about two minutes, especially
if you've already gone over exactly the same files about once every two
days, for the last three weeks, and you know pretty much instantly the
bits that you want to keep and those that you recognise were added by
someone else, very recently.
I wasn't kidding about taking six hours to merge one hours' work by
another developer, using diff and patch. I wasn't sure exactly which
files in which directories had been modified (about ten, out of about a
hundred files), and so had to check the whole lot... again, having just
spent 48 hours manually merging an extra 70,000 lines of smbd code into
the Samba TNG branch. Now, using
dirdiff, it's a pretty trivial task to keep up-to-date. I still have to
do cvs diff -d -u -w -b -B > diff.output and check the output, before
committing... just to make absolutely sure.
I hate X-windows. I think it's a complete waste of a good computers'
time to run graphics. You can't edit two files and press
alt-f1,f2,f1,f2 page-down f1 page-down, alt-f2,f1 page-down f1 page-down
to compare two files, and even if you could, they would be displayed in
some stupid variable-width font. [I use this console-screen-switch
technique *as well as* diff, quite
frequently: the human eye works by detecting changes, and they show up
*really* well when you do this, *especially* when doing comparative
hex-dumps of Windows NT Network traffic and corresponding Samba Network
traffic to find out the exact, unknown, undocumented bit-patterns that
*might* be the cause of
a major lack of functionality in Samba - SMB is like that...].
So what caused me, who on receipt of a .doc or .xls file will resort to
running strings on it in order to deduce its contents, or sends it to
someone else for printing, even if it's confidential, to use graphical
interfaces?
dirdiff.
http://samba.org/cgi-bin/cvsweb/dirdiff
public cvs instructions