Hi Leslie,
actually SVN provides more elegant solutions. I suppose by *flip* you
mean having two
checked-out versions and changing back and forth between them. The
"normal" way
of working in *svn* is to:
*svn co* only once, and to *svn up* to get the latest version or *svn up
-rXXX* to go back
to revision *XXX*. Also useful is *svn **diff -rXXX* or *svn diff
**-rXXX:YYY *to find
the differences between the current version (as per *svn up*) and
version*XXX *or
the difference between versions *XXX* and *YYY*.
Best Regards,
Jürgen Sauemann
On 05/17/2017 04:33 AM, Leslie S Satenstein wrote:
Portability in my review of the code is based on Linux/BSD/UNIX and
not with other systems.
I would like to see diffs of changes. By the way, I only run svn co
... to compile a new version.
If it works out, I flip the previous version with the current and wait
the next update.
Regards
*
Leslie
*
*Leslie Satenstein*
*Montréal Québec, Canada*
**
------------------------------------------------------------------------
*From:* Blake McBride <blake1...@gmail.com>
*To:* fwei...@crisys.com
*Cc:* GNU APL <bug-apl@gnu.org>
*Sent:* Tuesday, May 16, 2017 7:51 PM
*Subject:* Re: [Bug-apl] 950 )HELP Issue, and mem.cc
On Tue, May 16, 2017 at 2:30 PM, Fred Weigel <fwei...@crisys.com
<mailto:fwei...@crisys.com>> wrote:
...
Find attached a first cut at shared memory support (mem.cc). It
allows mmap() ...
A friendly plea to remain portable. I've seen it time and again, a
great, portable software package comes out. And then they start
tweaking it peace by peace until, for largely no reason, it becomes
unportable and unmaintainable. In 35 years, I've not needed memory
mapped files (but I understand that that may be due to the kinds of
problems I faced). Still, I hope an eye is kept on simplicity and
portability. I wouldn't start adding all sorts of cute stuff.
Just my two cents.
Blake