===== 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
message.
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()
subroutine).
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
reconfigurations.
===== 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
to.
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:
-m
-f
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.