Re: [Gnu-arch-users] Re: Utterly painless arch?

[Stephen J. Turnbull]

>>>>> "John" == John Goerzen <address@hidden> writes:

    John> IOW, they *CAN'T* read the tla docs to find out what to do
    John> here, because it's not covered.

That's why Tom recommended a self-teaching partner app (for Emacs, but
it would work for scripting, too).

    >> They're not complicated, they just require the overhead of
    >> studying docs.

    John> I don't think that's bad.

I agree with you on this, but ... .

    John> To appreciate tla and use it well, you *have* to study the
    John> docs.

This depends on how you define "well", as "with great skill" or "with
great profit".  For example, I'd really like to get my advisees using
version control, even in a one-branch, straight-line fashion so I can
_show_ them (with diff) just how trivial the revisions they are making
are.  One session of abuse and torture should be enough to get most of
them to do the diffs themselves, first.  :-)  That's "well" in the
sense of "with great profit."  But it requires only an arch-newbie
script and "tla commit", no study.  ("Bureaucratic secretary" would
also fit this scenario, as I implied to Tobias.)

On the other hand, I'd really like them to stop using the "three copy"
architecture that word processors have encouraged (write an intro,
copy it into the body, copy it into the conclusion, submit the draft).
But trying different styles requires that they see a profit to doing
so rather than stonewalling (they know from history that there will be
extremely strong pressure on me to accept any paper in the end), so
the cost of working on branches must be made very low, and the cost of
merging from one branch to another must also be low.

In this context you suggest CVS.  It _might_ do, but it has three big
demerits relative to Arch.  The first is that CVS is much worse at
branching.  The second is that it requires somebody to administer the
central repository.  (If there are write controls, surely this
requires admin intervention---a cvs-newbie script couldn't be
self-contained in the same way an arch-newbie script can, and should,
be.)  The third is that security among Japanese students is extremely
lax.[1]  I have to assume that people will have access to each other's
areas, and I don't want to think about whether that can cause problems
repository-wide and certainly want to avoid the security admin
headaches.  With personal repositories, there's no chance such
foolishness can take someone else's repository down.

There's a fourth possible merit to Arch, which is the ease of sharing
in the "if you like it, pull address@hidden/c-b-v-p-NN" style of interchange
which is acutely visible on all the arch channels.  That depends on
whether my students are doing closely related topics and doing a lot
of computation or not (papers must be original, programs may be shared
according to departmental standards), so I don't know whether it will
be meaningful in the long run.

Of course this last does absolutely require them to "appreciate tla
and use it well" (== skillfully), but they could (I'd hope) "grow
into" that appreciation.[2]

So I'm of two minds.  Basically, I'm an elitist bastard by temperament
(cf. http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/elitism.html),
but in practice _wide diffusion_ of certain tools is often far more
beneficial than the damage caused by even widespread less-than-elite
use of those tools can offset.


Footnotes: 
[1]  Many of those I've asked have given their administrative password
(which allows them to access grades and request transcripts) to
someone else, and most have given their file share password to someone
else (it's the foolproof way to create an audit trail faking execution
of homework programs; I have no idea how many faculty are fooled...).

[2]  However, I can imagine that protocol being formalized, so that a
script or GUI implementing it as a standard could be written.

-- 
Institute of Policy and Planning Sciences     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.