Re: ada writing guide

[Ted Dennison <dennison@telepath.com>]

In article <8dhuuu$ou5$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8dhqi7$jv3$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:

> T.E.D. seems to be describing a system in which people use
> neither approach, and merrily destroy one anothers fixes by
> updating old versions. I would NOT call this version control
> at all.

I must be a really crappy communicator if a complaint about an emacs
configuration file being difficult to control from long-lived sessions
comes off this horribly off-target. I guess I should quit while I'm
behind, but...

Substitute "emacs" for "people", and "exception file changes" for
"fixes", and that's my exact problem with it.

Perhaps if I rephrase it this way: How easy is it for a "fix" to get
wiped out using emacs? I have used 6 different revision control systems,
but the following process will work with all of them (ClearCase requires
custom emacs lisp files, but they exist).

  First, for a normal source file:
    The file has to be explicitly opened in an emacs buffer.
    The file has to be updated outside of the emacs buffer, while the
emacs session remains running.
    The updated version has to be checked in.
    The emacs user has to check the source file out *outside* of emacs,
while it is already in the emacs buffer. Checking it out inside of emacs
would cause the buffer to get updated with the latest copy.
    If the buffer was read-only when the user loaded it, the user must
manually change it to read/write without realoading the file. This can
be done, but few would routinely do it that way with managed files.
    Next the user would have to edit the buffer (containing the older
version). This will cause emacs to dispaly a prompt asking if they
really want to edit, as this isn't the latest version. The user *must*
type a "y" to proceed.
    Next the user must save the buffer. Again, a warning will be
displayed stating that this isn't the latest version. The user must type
a y at the prompt (which they wouldn't normally have to do) to save the
file. A backup of the old file will be created by emacs.
    Finally, the user must check in the buffer (inside or outside of
emacs).

Reading over all this, it should be clear to anyone that there is *no
way* all this is going to happen on accident.

Now, for an exceptions file:
   The user starts up emacs
   A second user (or possibly the same user with a second emacs session)
checks the file out.
   The second user modifies it somehow.
   The second user checks the file in.
   The first user checks the file out.
   The first user types Ctrl-C Ctrl-Y in their emacs session.
   The first user checks the file in.

No warnings are given, no backups are made. The old version is
over-written. Even for those who know the danger, this would be easy to
accidentally do.

Again, if anyone is still confused, I'm *not* saying this can happen
with normal source files. Its a problem with the emacs Ada-mode
capitalization files, which is cheifly an artifact of the fact that the
tool that uses them never rereads them once it has started. It would be
roughly equivalent to sources only you had to issue some special command
or reboot every time you wanted your compiler to read the latest source
files from disk.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.