===== cvslines 1.6.9 (adaption to work with newer cvs version, public release)
  Adopted to cvs > 1.11.2, cvslines now only works with at least this version.

===== cvslines 1.6.8 (adaption to work with newer cvs version, public release)

  Adopted to cvs 1.11, added pserver support, no need to have remote access
    to the cvs server any more, everything is done via the cvs client.

  Added support for Windows/CygWin environment, cvslines is provided as package
    for the Cygwin-Installer. Cvslines needs CygWin to be installed with
    Unix-Linebreaks, and the CygWin-cvs client has to be used.

  Bugfix: Adding/Removing of files was not working properly.

  Limitations: cvslines doesn't handle binary properly, don't use it with
    binary files.

  Tested with Windows/Cygwin and newer Linux Plattforms

===== cvslines 1.6.7 (bug fix; public relaase)

  Now tested on DEC/OSF1 V4.0.
    Note: you may need to set RCSBIN in the config file, to override
    use of an older RCS that DEC seems to ship in /usr/bin with DEC
    Unix 4.0.

  Bugfix: don't do &sticky_store() with -i! The impact of the bug
    was an annoying and possibly alraming, though benign, error

  Bugfix: changes for handling adds to branches correctly.
    Previously, "cvs add"ing a file on branch line, where the file had
    previously been added added on the trunk, would get
    confused... cvslines' would *always* expect the new add to be a
    branch from 1.1, but that's not how CVS works.

===== cvslines 1.6.6 (debug feature; bug fix)

  Bugfix: Handle cases where RCS repositories (,v files) don't have
    a "comments" section (using the newly added skip_to_deltas()

  Bugfix: reset  $Rcstok_Buf = ""; at appropriate times. I'm not sure
    I've ever observed it cause an error, but seems like it could.

  Debug Feature: -rcslog for testing the rcslog function.

  Bugfix: Apparently, cvs can sometimes put a string I didn't expect
    (not of the the form ".../Initial /..." in the date
    field for newly added (but not yet commited) files. Fixed cvslines
    to be immune to this, by looking for fields *not* a valid date,
    rather for ones that *do* start with "Initial ".

===== cvslines 1.6.5 (cvslines.disable)

  If the file cvslines.disable exists along side of the
  cvslines.config file for a module, then it's contents will be
  displayed when anybody attempts a commit, and the commit will be
  refused. This is a useful way to disable checkins during

===== cvslines 1.6.3 (bug fix)

  Bugfix: cvslines determines incorrect "current line" when it's
    been changed from that of the working tree for an individual file.

  This release fixes a bug wherein "cvslines commit" will fail to
  determine the correct current line for a file, when the file has
  been individually updated to other than the default tag for the
  working tree containing the file.

  E.g., in a tree checked out from the head of the RCS trunk with

    % cvs checkout module/dir
    cvs checkout: Updating module/dir
    U module/dir/file

  If you then did

    % cd module/dir; cvs update -r BRANCH file
    U file

  ...then modified "file", and tried to commit the change, cvslines
  commit would erroneously act as if the working branch for the file
  was still the head.

  With the bugfix in this release, cvslines will correctly treat the
  workin file as being on the BRANCH branch, even though it's in a
  "head" working tree.

===== cvslines 1.6 (features)

Sticky lines answers

  For any given execution, cvslines it will only ask about each line
  of development once; for subsequent files, cvslines will use the
  answer supplied previously. To disable this (i.e., to revert to the
  older behavior, wherein cvslines always inquires about including
  the mods to each file for each line), use the new "-i" option.

Lines groups

  cvslines now supports the notion that some sets of lines of
  development can be intentionally more isolated from others. These
  sets are called "lines groups" by cvslines.

cvslines commit -n

  cvslines now supports a "-n" option that works like "cvs -n" or
  "make -n", i.e., a "tell me what you *would* do" option. With -n,
  cvslines will still do the "planning phase", where it determines,
  for each file, what line(s) of development will get the
  changes. However, cvslines will then only display the steps for
  carrying out the resulting "commit plan". The cvs repositories will
  not be modified.

Batch mode

  cvslines remains a primarily interactive tool, but in certain
  circumstances, it may be useful to execute it in a noninteractive
  mode, or at least to reduce the amount of interaction required
  during a given execution. To this end, cvslines now supports a
  "batch mode".

  For the greatest flexibility, cvslines now provides separate options
  that allow you to turn off (or to supply answers noninteractivly
  for) certain of the interactions it normally requires. These are:

  Noninteractive line inclusion specifications

    Normally, cvslines will prompt you to determine which other
    line(s) of development a given set of changes should be applied

    A pair of new options "-all[-...]" and "-only[+] can
    be used to specify which lines (in addition to the one
    represented by the working tree) should get the changes.

    "-all", by itself, is the same as answering "yes" to every
    "include this change in ...." question that cvslines would ask;
    you can specify "every line except for" with the form
    "-all-[...]". Note that there are no spaces within the
    -all- argument; for example, "-all-R3.1.x-R4.0" would be the
    same as answering yes to every "include this change in ..."
    question, *except* for the R3.1.x and R4.0 lines.
    Similarly, "-only", by itself, is the same as answering "no" to
    every "include this change in ...." question that cvslines would
    ask; you can specify "only lines ..." with the form
    "-only+[...]". Note that there are no spaces within the
    -only+ argument; for example, "-only+R4.0" would be the same
    as answering no to every "include this change in ..."  question,
    *except* for the R4.0 line.

    Of course, cvslines will *always* assume that you want the changes
    for a given commit to be included in the line represented by the
    current working tree.
    [Yeah, I know, have "-o" and "-only" as separate unreleated
    options is pretty sleazy. But for some reason it seems like an OK
    thing to do.]

  Noninteractive log messages

    Normally, when you use cvslines commit, you will need to enter a
    log message interactively. cvslines now supports two options that
    allow you to supply the log message either on the command line, or
    in a file:


  Plan step execution

    By default, cvslines will prompt you with "cvslines: [press Return
    to]>" to confirm execution of each step in the commit plan. This can
    be disabled with the "-x" option.

  For completely "batch mode" operation, use "cvslines commit -b".
  When you do so, cvslines will insist that you supply line inclusion
  and log message information with one each of (-all or -only) and (-m
  or -f).

  -b implies -x.

  Normally, after determining which lines you want a given change to
  be applied to, cvslines will show you a summary of what will be
  done, including the new RCS revisions that would be created for each
  affected line of development, and then prompts for your approval
  with "Proceed? ". -b disables this confirmation.

  Without -b, cvslines quietly gets out of the way when it sees that
  its standard error stream is not a tty; With -b, cvslines will do
  its thing even when the standard error is a tty.

  Finally, with -b, cvslines will skip any commit for which merge
  conflicts were detected, and print a summary showing all such cases
  at the very end of its output.

  Note that, in batch mode (or, without -b, where either of (-f or -m)
  or (-all or -only) are used, the answers you supply will apply to
  *all* files affected by the commit. Using cvslines in interactive
  mode is more flexible in this regard.

Verbosity Restraint

  A new option "-q" inhibits cvslines from showing the status summary
  and commit plan summary for each file.

Most of the features explained above can be controlled by variables in
your ~/.cvslinesrc file. These can be used to customize cvslines to
get the default behavior that you prefer. See the cvslines.1 man page
for more information.