Re: editing log message

[Bob Proulx]

Mike Maxwell wrote:
> >Yes.  The read-one-line-at-a-time input method of rcs that we all know
> >and don't like very well today.
> 
> Bill Poser and I looked at the source code, and it appears it wouldn't 
> be too hard to plug in a call to the readline library (libreadline) in a 
> loop, so that the loop exits when the user types a line consisting of 
> just a period.

Yes.  That is the code.

I still think that linking with libreadline would only be a half
solution.  It would edit a single line.  But what if after typing in
your second line of the log message that you discover that you want to
make a change to the first line of the log message?  Since that was on
the previous line already entered then having the ability to edit the
line using libreadline does not help you.

You can test out this behavior by using the rlwrap command.

  http://utopia.knoware.nl/~hlub/uck/rlwrap/

[
  On my Debian based system rlwrap can be installed using this following
  command.  (This is provided as an example.  On your system you may
  need to do different things or to get the source code and compile it
  yourself.)

    sudo apt-get install rlwrap
]

The rlwrap command can be used with rcs commands.  This has the same
effect as if the command were modified to link with libreadline only
by using the wrapper this works with commands not linked with
libreadline.  This gives you a chance to preview your proposed change
to link with libreadline.

  rlwrap ci -u somefile

Using rlwrap in this way allows you full use of libreadline for
commands that were not linked with libreadline.  I just tried this
on my system to verify that it would all work as I am describing and I
was able to edit individual lines in the log message.

Please try rlwrap with ci and see if that is the editing mode that you
want.  I suspect that you will find that it is not quite what you want
because it only allows editing of a single line at a time.  I think
that is only a half solution and would not really solve the problem
well enough to justify cracking open rcs for this change.  Really what
is needed is a full editor for the entire log message at that point.

> ... if Bill and I were able to modify rcs so it used the
> readline library, would it be of general enough interest to get into
> a new version of rcs?

That would be up to the rcs maintainer.  I am simply a long time rcs
user and am speaking for myself.  But because rlwrap works very well
in this regard I would personally be inclined against it.  I feel that
it is not needed because rlwrap already provides it and IMNHO it is
only a half solution at best.  Even with it I think most people would
not think that it is enough.

Also 'rcs' is like 'ed', one of those programs that has been around
forever and is used as a standard by so many others that you hate to
touch it.  Doing so is almost certainly going to cause trouble for
people somewhere.  So cracking it open really needs a strong return
value on the risk created.

> I have the choice, but my fingers know rcs :-).  I use it both on
> Linux and Windows (the latter using the very nice CS-RCS front end).

I am a long term rcs user myself so I sympathize.

> Also, some of these other systems apparently don't play well with
> Windows (the wikipedia article on 'git' lists that as a drawback).

Yes that is a drawback for some people.  Git is a native GNU/Unix
system and has not yet been fully ported to MS-Windows.  There is work
progressing that direction though and I expect in the future it will
be fully available there.  It is too popular not to be ported.

One of the reasons I think git appeals to me is for the same reason
that rcs appeals to me.  Sometimes I find myself in a place where I
want to version control a file.  I don't want to create a lot of
overhead.  I will probably throw the entire thing away next week.  But
for the *right now* I want to keep the file version so that I can
debug my changes and return to the previous state while debugging.
For example a configuration file /etc/foo/foo.conf.  I often just want
to keep track of the changes for a while but not forever.

With RCS:

  cd /etc/foo
  ci -l -t- -m'Import file.' foo.conf
  ...edit foo.conf, check it in...
  ci -l -m'Changed file.' foo.conf
  ... clean up and throw everything away ...
  rm -f *,v

Previously using rcs was my tool of choice.  Simply check the file and
keep the version history as long as needed.  Make changes with
confidence that I can return to the previous version and allow me to
debug my configuration.  Throw it away when I don't care anymore.
Very light and useful.

Using CVS or Subversion is slightly more difficult because I would
need to set up a version server, probably on the local machine right
next to the files that I wanted to keep in it.  This is not difficult
but it is not as light weight of a solution as offered by rcs.  I
would probably not use cvs/svn as casually as I would use rcs because
of this.  Git is faster than cvs/svn and because it keeps the
respository in the local directory (the same as rcs does) is usually
my choice for a quick and light version control of a random file here
or there.  Here is a comparison.

With CVS:

  cd /etc/foo
  mkdir cvs
  cvs -d $PWD/cvs init
  mkdir $PWD/cvs/foo
  cvs -d $PWD/cvs co -d . foo
  cvs add foo.conf
  cvs commit -m 'Import file.'
  ...edit foo.conf, check it in...
  cvs commit -m'Changed file.'
  ... clean up and throw everything away ...
  rm -rf CVS cvs

With SVN:

  cd /etc/foo
  svnadmin create $PWD/svn
  svn co file://$PWD/svn .
  svn add foo.conf
  svn commit -m 'Import file.'
  ...edit foo.conf, check it in...
  svn commit -m'Changed file.'
  ... clean up and throw everything away ...
  rm -rf .svn svn

With Git:

  cd /etc/foo
  git init-db
  git add foo.conf
  git commit -m'Import file.'
  ...edit foo.conf, check it in...
  git commit -m'Import file.'
  ... clean up and throw everything away ...
  rm -rf .git

These are all very similar but there are important differences.  Note
that the 'init-db' step both created the repository and effectively
prepared it for use all in one step.  In cvs or svn the creation and
the preparation are more typing and the information content needed is
higher and more exacting.  I can type 'git init-db' in my sleep but to
type in 'svnadmin create $PWD/svn' and then 'svn co file://$PWD/svn .'
I need to think about it.  With cvs 'cvs -d $PWD/cvs co -d . foo' is
incrementally more mentally taxing.  I suggest that anyone interested
use the tools enough to get an understanding of the similarities and
differences among them and make their own decisions.

> If I did go with another version control system, I'm not sure which one 
> it would be.  I presume cvs is still a contender,

CVS is still actively used and supported.

> and offers advantages over RCS when multiple users want to modify
> the same file (although I haven't wrapped my mind around how that
> works--most of my work up until this point has been single-user
> modifications, namely my own).

They work the same as rcs works in this case.  The classic rcs
paradigm that I am familar with is to use symbolic links and NFS to
share an rcs repository.

  ln -s /nfs/path/to/rcs-repository/foo/RCS .
  ln -s /nfs/path/to/rcs-repository/foo/subdir1/RCS subdir1/
  ln -s /nfs/path/to/rcs-repository/foo/subdir2/RCS subdir2/

At that point multiple users can work on the same rcs files and share
the rcs repository.

But I assume you are talking about the rcsmerge functionality to merge
changes together?  Start with understanding rcsmerge and you will have
a good handle on understanding how merging works in the other systems.

> Another criterion I would have for a replacement version control system 
> is that it treat XML well.

I am not aware of any version control systems designed specifically
for managing XML data.  Since all of these manage even binary data to
some extent I expect that they would all work on xml data too.
Efficiency and human readability of the changes excepted.

Bob