Re: ada writing guide

["Samuel T. Harris" <samuel_t_harris@Raytheon.com>]

Ted Dennison wrote:
> 
> In article <874s8yeg81.fsf@deneb.cygnus.argh.org>,
>   Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> > Ted Dennison <dennison@telepath.com> writes:
> >
> > > 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.
> >
> > This can't happen with systems like CVS where each user works on his
> > private copy of the source files.  The master files are often not
> > directly accessible.  Problem solved. ;)
> 
> Hmm. I use CVS at home, but I guess that's not multiuser (yet, perhaps
> It'll be that way when my kids are older :-)  ).
> 
> I'm still not convinced CVS wouldn't have the problem too. But at least
> the process give you one hint. I see it working this way.
> 
>   User A does a "cvs checkout" of the repository
>   User B does a "cvs checkout" of the repository

Here is your problem. Any tool which does not provide some
check on multiple check-outs and a way to prevent then
is seriously broken IMO. Access controls become more and more
important as project size grows, or the separation between
developers increases. Multiple changes to the same source
simply cannot be allowed. Merging is just not a viable
mitigator to this chaotic sequence of events.

>   User A starts up emacs (which reads the exception file into memory).
>   User B starts up emacs (which reads the exception file into memory).
>   User A hits Ctrl-C Ctrl-Y
>   User A does a "cvs commit" on the exception file
>   User B finds out there were changes, and does a "cvs update"
>   User B hits Ctrl-C Ctrl-Y (unknowingly wiping out user A's changes)

With access controls, this would not happen because the B's
check-out would have failed. This mentality of letting anyone
do anything and merge it all together later is simply frought
with too many pitfalls.

>   User B does a "cvs commit"
> 
> At least this way, there is a manual updating step in there, where the
> wise user could say, "I'd better bring my emacs up to date, just to be
> safe." But it'd still be awfully easy to forget, or overlook a running
> session somewhere.

There in lies the rub. Merging later depends upon that later
actually coming. Better to prevent multiple changes up front.
User A and B have a file based upon some common version.
User A checks it out, makes changes, and then checks it in.
User B checks it out and fails because he does not have the
latest version. User B can not attempt the check out again
and force the system to ignore User A's changes (B had better
know what he is doing here) or User B can accept the changes
from User A and then check out the file.

> 
> --
> T.E.D.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"