Next: Bugs Prev: Customization Up: Top
Pcl-cvs is still under development and needs a number of
enhancements to be called complete. Below is my current wish-list for
future releases of pcl-cvs. Please, let me know which of these
features you want most. They are listed below in approximately the
order that I currently think I will implement them in.
* Rewritten parser code. There are many situations where pcl-cvs
will fail to recognize the output from CVS. The situation could
be greatly increased.
* `cvs-status'. This will run `cvs status' in a directory and
produce a buffer that looks pretty much like the current *cvs*
buffer. That buffer will include information for all
version-controlled files. (There will be a simple keystroke to
remove all "uninteresting" files, that is, files that are
"Up-to-date"). In this new buffer you will be able to update a
file, commit a file, et c. The big win with this is that you will
be able to watch the differences between your current working file
and the head revision in the repository before you update the
file, and you can then choose to update it or let it wait for a
* Log mode. When this mode is finished you will be able to move
around (using `n' and `p') between the revisions of a file, mark
two of them, and run a diff between them. You will be able to
hide branches (similar to the way you can hide sub-paragraphs in
outline-mode) and do merges between revisions. Other ideas about
this are welcome.
* The current model for marks in the *cvs* buffer seems to be
confusing. I am considering to use the VM model instead, where
marks are normally inactive. To activate the mark, you issue a
command like `cvs-mode-next-command-uses-marks'. I might
implement a flag so that you can use either version. Feedback on
this before I start coding it is very welcome.
* It should be possible to run commands such as `cvs log', `cvs
status' and `cvs commit' directly from a buffer containing a file,
instead of having to `cvs-update'. If the directory contains many
files the `cvs-update' can take quite some time, especially on a
slow machine. I planed to put these kind of commands on the prefix
`C-c C-v', but that turned out to be used by for instance c++-mode.
If you have any suggestions for a better prefix key, please let me
* Increased robustness. For instance, you can not currently press
`C-g' when you are entering the description of a file that you are
adding without confusing pcl-cvs.
* Support for multiple active *cvs* buffers.
* Dired support. I have an experimental `dired-cvs.el' that works
together with CVS 1.2. Unfortunately I wrote it on top of a
non-standard `dired.el', so it must be rewritten.
* An ability to send user-supplied options to all the cvs commands.
* Pcl-cvs is not at all clever about what it should do when `cvs
update' runs a program (due to the `-u' option in the `modules'
file -- see `cvs(5)'). The current release uses a regexp to
search for the end. At the very least that regexp should be
configured for different modules. Tell me if you have any idea
about what is the right thing to do. In a perfect world the
program should also be allowed to print to `stderr' without
causing pcl-cvs to crash.
If you miss something in this wish-list, let me know! I don't
promise that I will write it, but I will at least try to coordinate the
efforts of making a good Emacs front end to CVS. See Note: Bugs for
information about how to reach me.
So far, I have written most of pcl-cvs in my all-to-rare spare time.
If you want pcl-cvs to be developed faster you can write a contract with
Signum Support to do the extension. You can reach Signum Support by
email to `email@example.com' or via mail to Signum Support AB, Box 2044,
S-580 02 Linkoping, Sweden. Phone: +46 (0) 13 - 21 46 00. Fax: +46 (0)
13 - 21 47 00.
automatically generated by info2www