[ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System

[ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System

[Dr. Volker Zell]

Hi

A new version of 'rcs' has been uploaded to a server near you.

 o Update to latest upstream release
 o Build for cygwin 1.7.16 with gcc-4.5.3
 o Uses cygport-0.11.0 for .hint files generation
 o debuginfo package included


rcs NEWS:
=========

  - Bugs fixed

    - Debug output removed

        Due to an oversight, release 5.8 rlog included code to write
        debugging output to stderr for invocations using the '-d' option
        and a date range (e.g., 'rlog -d 2010<2012').

    - Criteria for avoiding read-only checks refined

        For "make check", some test cases are inhibited if the user
        running the test is not effectively blocked from writing a
        purportedly read-only file, such as when "make check" is run by
        the super user, or for certain (weird) NFS situations.

        Previously, to determine this condition, we considered only the
        operating system type, a very crude (and incomplete) proxy.
        Now, we explicitly check with a shell sequence comprising the
        umask(1) and test(1) commands, plus output-redirection.

    - Regression in '-zLT' handling

        On a 64-bit x86 system, RCS 5.8 introduced a regression whereby:

         rlog -zLT -d>2011-05-04

        would select the correct entry but display its date always with
        default (01) month and day, i.e., YYYY-01-01.  This is now fixed
        (see also tests/t320).

    - Regression in 'ci -d -T' handling

        RCS 5.8 introduced a regression whereby:

          ci -l -d -T FILE

        would set the mtime of RCS/FILE,v (the comma-v file) to the
        epoch.  This is now fixed (see also tests/t810).

  - Use 'diff --label' instead of 'diff -L'

        Previously, RCS used GNU diff's '-L' option.  According to Paul
        Eggert (a GNU diffutils maintainer):

          That option has been undocumented since diffutils 2.8
          (released in March 2002) and the option is intended to
          be replaced sometime soon with a different meaning.

        Now, RCS uses 'diff --label', thus immune to the planned change.

  - Miscellaneous changes
    - Make help extraction noisy (on failure)
    - Silence some compiler warnings
    - Increase coverage of "make check"

  - Documentation improvements

    - Manpage rcsintro(1) dropped

        This manpage is redundant, and (arguably) should not have been
        in section 1 in the first place.

    - Use "Invoking COMMAND" instead of "COMMAND" as node names

        This makes it easier for 'info --usage COMMAND' to DTRT, and
        makes GNU (info "(standards) Manual Structure Details") happy.

    - explicitly UTF-8

        This is to prepare for a (future) GNU Texinfo release that
        renders @code in a more pretty way when the encoding is UTF-8.
        If you're reading this (from the future) with such a Texinfo at
        hand, feel free to regenerate the docs in doc/ prior to install.

    - CVS is not GNU

        Previously, we incorrectly said "GNU CVS", succumbing to a
        common misunderstanding.  Now we know better.

  - TAGS file no longer distributed

        To create, configure normally and do "make TAGS".

  - New configure script option '--enable-coverage'

        Specifying '--enable-coverage' causes '_Exit' to be an alias for
        'exit' and CFLAGS to append '--coverage' if the compiler is GCC.
        This is needed because the coverage machinery writes the .gcda
        files only on 'exit'.

        This option is for maintainers; most people can ignore it.

  - Portability improvements
    - Use more gnulib modules
    - Use portable Makefile subst-ref variable syntax
    - Use portable shell command-output interpolation syntax
  - Maintenance tools upgraded
    - GNU Automake 1.12
    - GNU Autoconf 2.69
    - gnulib-tool (GNU gnulib 2012-06-03 16:29:00) 0.0.7432-f6c24-modified


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO
================================


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:


http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then look at the "List-Unsubscribe: " tag in the
email header of this message.  Send email to the address specified
there.  It will be in the format:


cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: [ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System

[Wagemans, Peter]

Dear Dr. Zell,

> [ANNOUNCEMENT] Updated: rcs-5.8.1-1: The Revision Control System

Do you perhaps know whether this version fixes the file corruption
problem noticed earlier on this list for 5.8, or should we stay with
5.7 to avoid corrupting large RCS files?

Short problem description (what I think is happening):

For large files, the check-in tool ci decides to do file descriptor IO
instead of memory mapped IO.

Ci reads the start of the work file. This triggers the IO library to
fill its buffer, 64k in this case.

Ci dups the file descriptor and supplies it to a diff subprocess. The
file pointer is shared.

Diff reads the entire file. This places the file pointer at the end of
the file.

Ci rewinds the work file. The IO library sees that the start of file
position is in the current buffer and simply resets the buffer
pointer.

Ci wants to read the entire work file to place it in the new rcs
file. At the end of the 64k buffer, the IO library reads the file
descriptor for the next 64k.  But the file pointer of the file
descriptor is still at the end of the file, so ci gets an EOF and
thinks the work file copy is complete.

Thus the content of the last version in the rcs file is truncated to
64k and the rcs file most likely becomes inconsistent, since the edit
scripts to reproduce older versions from the last version refer to
lines that are no longer present.

If you do a check-in, check-out sequence, then you end up with a
truncated work file, corrupted rcs file, have lost recent work and
must resort to backups.

Regards,

Peter Wagemans