Re: [tlug] Linux Format magazine

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Lyle" == Lyle Saxon <Lyle> writes:

    Lyle> If the editor is good with standard text editors, then there
    Lyle> isn't any need for automation?

What do you think a "standard text editor" is?  It's just one form of
automation.  It might be optimal for this task, but the only optimal
piece of software I've ever met is /dev/null ;-)

Besides, Josh would never use a pencil and paper to do in 10 seconds
what he could spend hours lashing up a M4 script to do in RAM.
(Leaving the problem of output to the reader. :-)

    Lyle> Still - the editorial process should be the same.

That's an important criterion for automation, and altogether too often
is forgotten.  But any of the suggested "source configuration
managers" (SCMs) do this part fine, because they make no decisions at
all.  Instead, as you suggest:

    Lyle> I just want to stress that all versions should be readily
    Lyle> viewable and changes from any one of many contributers
    Lyle> should not be made automatically to the master file.

It seems impossible to not have a "current version", and changes by
any "authorized committer" will change the current version.  However,
all versions ever committed are preserved for all eternity (or until
the next unbacked-up hard drive failure, whichever comes first),
easily available, and there are facilities for automatically "mixing"
versions to create new versions never seen before.

    Lyle> In this automation you mention, does it leave the master
    Lyle> alone and save each incoming file as a separate file?

No, but don't worry about it.  You can think about it that way if you
like, it's almost equivalent.  The main issue that you'll run into is
that nobody has come up with a sane way to name the versions yet, so
you have to find out from somebody who already knows which one to ask
for.  (Sort of like connecting to a dotted quad without DNS.)

    Lyle> with a large file, changes should be clearly marked so the
    Lyle> editor knows exactly where the changes are.

This is one of the things that SCMs and their ancillary tools are very
helpful with.

    Lyle> Does it show both the old and new side-by-side, or just the
    Lyle> new text highlighted, underlined or indicated in some way?

Get to the command line on a Linux box, and type

$ cat <<EOT >A
A Dystopia
by Aldous Huxley
Hello, brave
new world!
EOT
$ cat <<EOT >B
A Dystopia
by Nitrous Oxide
Goodbye cruel
old world!
EOT
$ diff A B
$ diff -c A B
$ diff -u A B
$ diff -y A B
$ wdiff A B

You may have to install diff and wdiff if you don't have a developer's
workstation.  The package is called diffutils on Debian, YMMV.

There are nicer tools for this, but I think the raw text output from a
small number of tools will help emphasize the "kiso".  I've found
wdiff + proposed revision (ie, two separate files) to be an excellent
way to present my editorial advice to authors.  The biggest problem
I've had with it is the two poor fellows who thought they should send
their questions back to me in the same form and did it by hand!

(Also, diff and wdiff as such are not SCMs, but diff or a similar
program is used internally by almost all SCMs.)

Other information you might want to check out:  man sdiff, man merge,
man diff3 (do this _after_ man merge), man cvs, man svn.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.