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
