Go to the first, previous, next, last section, table of contents.
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
while longer.
-
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 know.
-
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 See section 9. Bugs (known and unknown) 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 `info@signum.se' 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.
Go to the first, previous, next, last section, table of contents.