798 lines
39 KiB
Plaintext
798 lines
39 KiB
Plaintext
The "TODO" file! -*-Indented-Text-*-
|
|
|
|
22. Catch signals for cleanup when "add"ing files.
|
|
|
|
24. Insist on a log message.
|
|
(If done, this should be configurable via commitinfo or some new
|
|
config file -kingdon, Jun 1995).
|
|
|
|
30. Add "rdiff" program option to the modules database (and "diff"
|
|
too?). (perhaps should think a little harder about what this is
|
|
trying to accomplish and what the best way is -kingdon, Jul 1997).
|
|
|
|
31. Think hard about ^C recovery.
|
|
One particular issue: RCS removes the ,foo.c, file on ^C and CVS
|
|
doesn't.
|
|
|
|
38. Think hard about using RCS state information to allow one to checkin
|
|
a new vendor release without having it be accessed until it has been
|
|
integrated into the local changes.
|
|
|
|
39. Think about a version of "cvs update -j" which remembers what from
|
|
that other branch is already merged. This has pitfalls--it could
|
|
easily lead to invisible state which could confuse users very
|
|
rapidly--but having to create a tag or some such mechanism to keep
|
|
track of what has been merged is a pain. Take a look at PRCS 1.2.
|
|
PRCS 1.0 was particularly bad the way it handled the "invisible
|
|
state", but 1.2 is significantly better.
|
|
|
|
45. Consider enhancing the "rdiff" and "tag" (rtag??) command support in
|
|
the module database -- they seem hard to use since these commands
|
|
deal directly with the RCS ,v files.
|
|
|
|
49. cvs xxx commands should be able to deal with files in other
|
|
directories. I want to do a cvs add foo/bar.c.
|
|
[[ most commands now use the generic recursion processor, but not all;
|
|
this note is left here to remind me to fix the others ]]
|
|
|
|
52. SCCS has a feature that I would *love* to see in CVS, as it is very
|
|
useful. One may make a private copy of SCCS suid to a particular user,
|
|
so other users in the authentication list may check files in and out of
|
|
a project directory without mucking about with groups. Is there any
|
|
plan to provide a similar functionality to CVS? Our site (and, I'd
|
|
imagine, many other sites with large user bases) has decided against
|
|
having the user-groups feature of unix available to the users, due to
|
|
perceived administrative, technical and performance headaches. A tool
|
|
such as CVS with features that provide group-like functionality would
|
|
be a huge help.
|
|
|
|
62. Consider using revision controlled files and directories to handle the
|
|
new module format -- consider a cvs command front-end to
|
|
add/delete/modify module contents, maybe.
|
|
|
|
63. The "import" and vendor support commands (co -j) need to be documented
|
|
better.
|
|
|
|
66. Length of the CVS temporary files must be limited to 14 characters for
|
|
System-V stupid support. As well as the length on the CVS.adm files.
|
|
|
|
72. Consider re-design of the module -o, -i, -t options to use the file
|
|
system more intuitively.
|
|
|
|
73. Consider an option (in .cvsrc?) to automatically add files that are new
|
|
and specified to commit.
|
|
|
|
79. Might be nice to have some sort of interface to Sun's Translucent
|
|
(?) File System and tagged revisions.
|
|
|
|
82. Maybe the import stuff should allow an arbitrary revision to be
|
|
specified.
|
|
|
|
84. Improve the documentation about administration of the repository and
|
|
how to add/remove files and the use of symbolic links.
|
|
|
|
85. Make symbolic links a valid thing to put under version control.
|
|
Perhaps use one of the tag fields in the RCS file? Note that we
|
|
can only support symlinks that are relative and within the scope of
|
|
the sources being controlled.
|
|
|
|
92. Look into this:
|
|
After a bit of soul searching via dbx, I realized my sin was that I'd
|
|
specified "echo" as the program to call from loginfo. The commit
|
|
procedure worked fine till it hit my echo, then silently aborted
|
|
leaving the lockfiles intact. Since I needn't use the loginfo
|
|
facility, I simply removed those commands and it all works.
|
|
|
|
93. Need to think hard about release and development environments. Think
|
|
about execsets as well.
|
|
|
|
98. If diff3 bombs out (too many differences) cvs then thinks that the file
|
|
has been updated and is OK to be commited even though the file
|
|
has not yet been merged.
|
|
|
|
100. Checked out files should have revision control support. Maybe.
|
|
|
|
102. Perhaps directory modes should be propagated on all import check-ins.
|
|
Not necessarily uid/gid changes.
|
|
|
|
103. setuid/setgid on files is suspect.
|
|
|
|
104. cvs should recover nicely on unreadable files/directories.
|
|
|
|
105. cvs should have administrative tools to allow for changing permissions
|
|
and modes and what not. In particular, this would make cvs a
|
|
more attractive alternative to rdist.
|
|
|
|
107. It should be possible to specify a list of symbolic revisions to
|
|
checkout such that the list is processed in reverse order looking for
|
|
matches within the RCS file for the symbolic revision. If there is
|
|
not a match, the next symbolic rev on the list is checked, and so on,
|
|
until all symbolic revs are exhausted. This would allow one to, say,
|
|
checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the
|
|
most recent 4.x stuff. This is usually handled by just specifying the
|
|
right release_tag, but most people forget to do this.
|
|
|
|
108. If someone creates a whole new directory (i.e. adds it to the cvs
|
|
repository) and you happen to have a directory in your source farm by
|
|
the same name, when you do your cvs update -d it SILENTLY does
|
|
*nothing* to that directory. At least, I think it was silent;
|
|
certainly, it did *not* abort my cvs update, as it would have if the
|
|
same thing had happened with a file instead of a directory.
|
|
|
|
109. I had gotten pieces of the sys directory in the past but not a
|
|
complete tree. I just did something like:
|
|
|
|
cvs get *
|
|
|
|
Where sys was in * and got the message
|
|
|
|
cvs get: Executing 'sys/tools/make_links sys'
|
|
sh: sys/tools/make_links: not found
|
|
|
|
I suspect this is because I didn't have the file in question,
|
|
but I do not understand how I could fool it into getting an
|
|
error. I think a later cvs get sys seemed to work so perhaps
|
|
something is amiss in handling multiple arguments to cvs get?
|
|
|
|
113. The "cvs update" command should tee its output to a log file in ".".
|
|
(why? What is wrong with piping stdout to "tee"? -kingdon, Jun 1995)
|
|
|
|
119. When importing a directory tree that is under SCCS/RCS control,
|
|
consider an option to have import checkout the SCCS/RCS files if
|
|
necessary. (This is if someone wants to import something which
|
|
is in RCS or SCCS without preserving the history, but makes sure
|
|
they do get the latest versions. It isn't clear to me how useful
|
|
that is -kingdon, June 1996).
|
|
|
|
122. If Name_Repository fails, it currently causes CVS to die completely. It
|
|
should instead return NULL and have the caller do something reasonable
|
|
(??? -what is reasonable? I'm not sure there is a real problem here.
|
|
-kingdon, June 1996).
|
|
|
|
123. Add a flag to import to not build vendor branches for local code.
|
|
(See `importb' tests in src/sanity.sh for more details).
|
|
|
|
124. Anyway, I thought you might want to add something like the following
|
|
to the cvs man pages:
|
|
|
|
BUGS
|
|
The sum of the sizes of a module key and its contents are
|
|
limited. See ndbm(3).
|
|
|
|
126. Do an analysis to see if CVS is forgetting to close file descriptors.
|
|
Especially when committing many files (more than the open file limit
|
|
for the particular UNIX).
|
|
|
|
127. Look at *info files; they should all be quiet if the files are not
|
|
there. Should be able to point at a RCS directory and go.
|
|
|
|
130. cvs diff with no -r arguments does not need to look up the current RCS
|
|
version number since it only cares about what's in the Entries file.
|
|
This should make it much faster.
|
|
|
|
It should ParseEntries itself and access the entries list much like
|
|
Version_TS does (sticky tags and sticky options may need to be
|
|
supported here as well). Then it should only diff the things that
|
|
have the wrong time stamp (the ones that look modified).
|
|
|
|
134. Make a statement about using hard NFS mounts to your source
|
|
repository. Look into checking NULL fgets() returns with ferror() to
|
|
see if an error had occurred. (we should be checking for errors, quite
|
|
aside from NFS issues -kingdon, June 1996).
|
|
|
|
137. Some sites might want CVS to fsync() the RCS ,v file to protect
|
|
against nasty hardware errors. There is a slight performance hit with
|
|
doing so, though, so it should be configurable in the .cvsrc file.
|
|
Also, along with this, we should look at the places where CVS itself
|
|
could be a little more synchronous so as not to lose data.
|
|
[[ I've done some of this, but it could use much more ]]
|
|
|
|
138. Some people have suggested that CVS use a VPATH-like environment
|
|
variable to limit the amount of sources that need to be duplicated for
|
|
sites with giant source trees and no disk space.
|
|
|
|
141. Import should accept modules as its directory argument. If we're
|
|
going to implement this, we should think hard about how modules
|
|
might be expanded and how to handle those cases.
|
|
|
|
143. Update the documentation to show that the source repository is
|
|
something far away from the files that you work on. (People who
|
|
come from an RCS background are used to their `repository' being
|
|
_very_ close to their working directory.)
|
|
|
|
144. Have cvs checkout look for the environment variable CVSPREFIX
|
|
(or CVSMODPREFIX or some such). If it's set, then when looking
|
|
up an alias in the modules database, first look it up with the
|
|
value of CVSPREFIX attached, and then look for the alias itself.
|
|
This would be useful when you have several projects in a single
|
|
repository. You could have aliases abc_src and xyz_src and
|
|
tell people working on project abc to put "setenv CVSPREFIX abc_"
|
|
in their .cshrc file (or equivalent for other shells).
|
|
Then they could do "cvs co src" to get a copy of their src
|
|
directory, not xyz's. (This should create a directory called
|
|
src, not abc_src.)
|
|
|
|
145. After you create revision 1.1.1.1 in the previous scenario, if
|
|
you do "cvs update -r1 filename" you get revision 1.1, not
|
|
1.1.1.1. It would be nice to get the later revision. Again,
|
|
this restriction comes from RCS and is probably hard to
|
|
change in CVS. Sigh.
|
|
|
|
|"cvs update -r1 filename" does not tell RCS to follow any branches. CVS
|
|
|tries to be consistent with RCS in this fashion, so I would not change
|
|
|this. Within CVS we do have the flexibility of extending things, like
|
|
|making a revision of the form "-r1HEAD" find the most recent revision
|
|
|(branch or not) with a "1." prefix in the RCS file. This would get what
|
|
|you want maybe.
|
|
|
|
This would be very useful. Though I would prefer an option
|
|
such as "-v1" rather than "-r1HEAD". This option might be
|
|
used quite often.
|
|
|
|
146. The merging of files should be controlled via a hook so that programs
|
|
other than "rcsmerge" can be used, like Sun's filemerge or emacs's
|
|
emerge.el. (but be careful in making this work client/server--it means
|
|
doing the interactive merging at the end after the server is done).
|
|
(probably best is to have CVS do the non-interactive part and
|
|
tell the user about where the files are (.#foo.c.working and
|
|
.#foo.c.1.5 or whatever), so they can do the interactive part at
|
|
that point -kingdon, June 1996).
|
|
|
|
149. Maybe there should be an option to cvs admin that allows a user to
|
|
change the Repository/Root file with some degree of error checking?
|
|
Something like "cvs admin reposmv /old/path /new/pretty/path". Before
|
|
it does the replace it check to see that the files
|
|
/new/pretty/path/<dir>/<files> exist.
|
|
|
|
The obvious cases are where one moves the repository to another
|
|
machine or directory. But there are other cases, like where the
|
|
user might want to change from :pserver: to :ext:, use a different
|
|
server (if there are two server machines which share the
|
|
repository using a networked file system), etc.
|
|
|
|
The status quo is a bit of a mess (as of, say, CVS 1.9). It is
|
|
that the -d global option has two moderately different uses. One
|
|
is to use a totally different repository (in which case we'd
|
|
probably want to give an error if it disagreed with CVS/Root, as
|
|
CVS 1.8 and earlier did). The other is the "reposmv"
|
|
functionality above (in which the two repositories really are the
|
|
same, and we want to update the CVS/Root files). In CVS 1.9 and
|
|
1.10, -d rewrites the CVS/Root file (but not in subdirectories).
|
|
This behavior was not particularly popular and has been since
|
|
reverted.
|
|
|
|
Note also RELATIVE_REPOS in options.h; it needs to be set for
|
|
changing CVS/Root (not CVS/Repository) to be sufficient in the
|
|
case where the directory has changed.
|
|
|
|
This whole area is a rather bad pile of individual decisions which
|
|
accumulated over time, some of them probably bad decisions with
|
|
hindsight. But we didn't get into this mess overnight, and we're
|
|
not going to get out of it overnight (that is, we need to come up
|
|
with a replacement behavior, document what parts of the status
|
|
quo are deprecated, probably circulate some unofficial patches, &c).
|
|
|
|
(this item originally added 2 Feb 1992 but revised since).
|
|
|
|
150. I have a customer request for a way to specify log message per
|
|
file, non-interactively before the commit, such that a single, fully
|
|
recursive commit prompts for one commit message, and concatenates the
|
|
per file messages for each file. In short, one commit, one editor
|
|
session, log messages allowed to vary across files within the commit.
|
|
Also, the per file messages should be allowed to be written when the
|
|
files are changed, which may predate the commit considerably.
|
|
|
|
A new command seems appropriate for this. The state can be saved in the
|
|
CVS directory. I.e.,
|
|
|
|
% cvs message foo.c
|
|
Enter log message for foo.c
|
|
>> fixed an uninitialized variable
|
|
>> ^D
|
|
|
|
The text is saved as CVS/foo.c,m (or some such name) and commit
|
|
is modified to append (prepend?) the text (if found) to the log
|
|
message specified at commit time. Easy enough. (having cvs
|
|
commit be non-interactive takes care of various issues like
|
|
whether to connect to the server before or after prompting for a
|
|
message (see comment in commit.c at call to start_server). Also
|
|
would clean up the kludge for what to do with the message from
|
|
do_editor if the up-to-date check fails (see commit.c client code).
|
|
|
|
I'm not sure about the part above about having commit prompt
|
|
for an overall message--part of the point is having commit
|
|
non-interactive and somehow combining messages seems like (excess?)
|
|
hair.
|
|
|
|
Would be nice to do this so it allows users more flexibility in
|
|
specifying messages per-directory ("cvs message -l") or per-tree
|
|
("cvs message") or per-file ("cvs message foo.c"), and fixes the
|
|
incompatibility between client/server (per-tree) and
|
|
non-client/server (per-directory).
|
|
|
|
A few interesting issues with this: (1) if you do a cvs update or
|
|
some other operation which changes the working directory, do you
|
|
need to run "cvs message" again (it would, of course, bring up
|
|
the old message which you could accept)? Probably yes, after all
|
|
merging in some conflicts might change the situation. (2) How do
|
|
you change the stored messages if you change your mind before the
|
|
commit (probably run "cvs message" again, as hinted in (1))?
|
|
|
|
151. Also, is there a flag I am missing that allows replacing Ulrtx_Build
|
|
by Ultrix_build? I.E. I would like a tag replacement to be a one step
|
|
operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build"
|
|
followed by "cvs rtag -d Ulrtx_Build"
|
|
|
|
152. The "cvs -n" option does not work as one would expect for all the
|
|
commands. In particular, for "commit" and "import", where one would
|
|
also like to see what it would do, without actually doing anything.
|
|
|
|
153. There should be some command (maybe I just haven't figured out
|
|
which one...) to import a source directory which is already
|
|
RCS-administered without losing all prior RCS gathered data.
|
|
Thus, it would have to examine the RCS files and choose a
|
|
starting version and branch higher than previous ones used.
|
|
(Check out rcs-to-cvs and see if it addresses this issue.)
|
|
|
|
154. When committing the modules file, a pre-commit check should be done to
|
|
verify the validity of the new modules file before allowing it to be
|
|
committed.
|
|
|
|
155. The options for "cvs history" are mutually exclusive, even though
|
|
useful queries can be done if they are not, as in specifying both
|
|
a module and a tag. A workaround is to specify the module, then
|
|
run the output through grep to only display lines that begin with
|
|
T, which are tag lines. (Better perhaps if we redesign the whole
|
|
"history" business -- check out doc/cvs.texinfo for the entire
|
|
rant.)
|
|
|
|
156. Also, how hard would it be to allow continuation lines in the
|
|
{commit,rcs,log}info files? It would probably be useful with all of
|
|
the various flags that are now available, or if somebody has a lot of
|
|
files to put into a module.
|
|
|
|
158. If I do a recursive commit and find that the same RCS file is checked
|
|
out (and modified!) in two different places within my checked-out
|
|
files (but within the realm of a single "commit"), CVS will commit the
|
|
first change, then overwrite that change with the second change. We
|
|
should catch this (typically unusual) case and issue an appropriate
|
|
diagnostic and die.
|
|
|
|
160. The checks that the commit command does should be extended to make
|
|
sure that the revision that we will lock is not already locked by
|
|
someone else. Maybe it should also lock the new revision if the old
|
|
revision was already locked by the user as well, thus moving the lock
|
|
forward after the commit.
|
|
|
|
163. The rtag/tag commands should have an option that removes the specified
|
|
tag from any file that is in the attic. This allows one to re-use a
|
|
tag (like "Mon", "Tue", ...) all the time and still have it tag the
|
|
real main-line code.
|
|
|
|
165. The "import" command will create RCS files automatically, but will
|
|
screw-up when trying to create long file names on short file name
|
|
file systems. Perhaps import should be a bit more cautious.
|
|
|
|
166. There really needs to be a "Getting Started" document which describes
|
|
some of the new CVS philosophies. Folks coming straight from SCCS or
|
|
RCS might be confused by "cvs import". Also need to explain:
|
|
- How one might setup their $CVSROOT
|
|
- What all the tags mean in an "import" command
|
|
- Tags are important; revision numbers are not
|
|
|
|
170. Is there an "info" file that can be invoked when a file is checked out, or
|
|
updated ? What I want to do is to advise users, particularly novices, of
|
|
the state of their working source whenever they check something out, as
|
|
a sanity check.
|
|
|
|
For example, I've written a perl script which tells you what branch you're
|
|
on, if any. Hopefully this will help guard against mistaken checkins to
|
|
the trunk, or to the wrong branch. I suppose I can do this in
|
|
"commitinfo", but it'd be nice to advise people before they edit their
|
|
files.
|
|
|
|
It would also be nice if there was some sort of "verboseness" switch to
|
|
the checkout and update commands that could turn this invocation of the
|
|
script off, for mature users.
|
|
|
|
173. We have a tagged branch in CVS. How do we get the version of that branch
|
|
(for an entire directory) that corresponds to the files on that branch on a
|
|
certain day? I'd like to specify BOTH -r and -D to 'cvs checkout', but I
|
|
can't. It looks like I can only specify the date for the main line (as
|
|
opposed to any branches). True? Any workarounds to get what I need?
|
|
|
|
174. I would like to see "cvs release" modified so that it only removes files
|
|
which are known to CVS - all the files in the repository, plus those which
|
|
are listed in .cvsignore. This way, if you do leave something valuable in
|
|
a source tree you can "cvs release -d" the tree and your non-CVS goodies
|
|
are still there. If a user is going to leave non-CVS files in their source
|
|
trees, they really should have to clean them up by hand.
|
|
|
|
175. And, in the feature request department, I'd dearly love a command-line
|
|
interface to adding a new module to the CVSROOT/modules file.
|
|
|
|
176. If you use the -i flag in the modules file, you can control access
|
|
to source code; this is a Good Thing under certain circumstances. I
|
|
just had a nasty thought, and on experiment discovered that the
|
|
filter specified by -i is _not_ run before a cvs admin command; as
|
|
this allows a user to go behind cvs's back and delete information
|
|
(cvs admin -o1.4 file) this seems like a serious problem.
|
|
|
|
177. We've got some external vendor source that sits under a source code
|
|
hierarchy, and when we do a cvs update, it gets wiped out because
|
|
its tag is different from the "main" distribution. I've tried to
|
|
use "-I" to ignore the directory, as well as .cvsignore, but this
|
|
doesn't work.
|
|
|
|
179. "cvs admin" does not log its actions with loginfo, nor does it check
|
|
whether the action is allowed with commitinfo. It should.
|
|
|
|
180. "cvs edit" should show you who is already editing the files,
|
|
probably (that is, do "cvs editors" before executing, or some
|
|
similar result). (But watch out for what happens if the network
|
|
is down!).
|
|
|
|
182. There should be a way to show log entries corresponding to
|
|
changes from tag "foo" to tag "bar". "cvs log -rfoo:bar" doesn't cut
|
|
it, because it erroneously shows the changes associated with the
|
|
change from the revision before foo to foo. I'm not sure that is ever
|
|
a useful or logical behavior ("cvs diff -r foo -r bar" gets this
|
|
right), but is compatibility an issue? See
|
|
http://www.cyclic.com/cvs/unoff-log.txt for an unofficial patch.
|
|
|
|
183. "cvs status" should report on Entries.Static flag and CVS/Tag (how?
|
|
maybe a "cvs status -d" to give directory status?). There should also
|
|
be more documentation of how these get set and how/when to re-set them.
|
|
|
|
184. Would be nice to implement the FreeBSD MD5-based password hash
|
|
algorithm in pserver. For more info see "6.1. DES, MD5, and Crypt" in
|
|
the FreeBSD Handbook, and src/lib/libcrypt/crypt.c in the FreeBSD
|
|
sources. Certainly in the context of non-unix servers this algorithm
|
|
makes more sense than the traditional unix crypt() algorithm, which
|
|
suffers from export control problems.
|
|
|
|
185. A frequent complaint is that keyword expansion causes conflicts
|
|
when merging from one branch to another. The first step is
|
|
documenting CVS's existing features in this area--what happens with
|
|
various -k options in various places? The second step is thinking
|
|
about whether there should be some new feature and if so how it should
|
|
be designed. For example, here is one thought:
|
|
|
|
rcs' co command needs a new -k option. The new option should expand
|
|
$Log entries without expanding $Revision entries. This would
|
|
allow cvs to use rcsmerge in such a way that joining branches into
|
|
main lines would neither generate extra collisions on revisions nor
|
|
drop log lines.
|
|
|
|
The details of this are out of date (CVS no longer invokes "co", and
|
|
any changes in this area would be done by bypassing RCS rather than
|
|
modifying it), but even as to the general idea, I don't have a clear
|
|
idea about whether it would be good (see what I mean about the need
|
|
for better documentation? I work on CVS full-time, and even I don't
|
|
understand the state of the art on this subject).
|
|
|
|
186. There is a frequent discussion of multisite features.
|
|
|
|
* There may be some overlap with the client/server CVS, which is good
|
|
especially when there is a single developer at each location. But by
|
|
"multisite" I mean something in which each site is more autonomous, to
|
|
one extent or another.
|
|
|
|
* Vendor branches are the closest thing that CVS currently has for
|
|
multisite features. They have fixable drawbacks (such as poor
|
|
handling of added and removed files), and more fundamental drawbacks
|
|
(when you import a vendor branch, you are importing a set of files,
|
|
not importing any knowledge of their version history outside the
|
|
current repository).
|
|
|
|
* One approach would be to require checkins (or other modifications to
|
|
the repository) to succeed at a write quorum of sites (51%) before
|
|
they are allowed to complete. To work well, the network should be
|
|
reliable enough that one can typically get to that many sites. When a
|
|
server which has been out of touch reconnects, it would want to update
|
|
its data before doing anything else. Any of the servers can service
|
|
all requests locally, except perhaps for a check that they are
|
|
up-to-date. The way this differs from a run-of-the-mill distributed
|
|
database is that if one only allows reversible operations via this
|
|
mechanism (exclude "cvs admin -o", "cvs tag -d", &c), then each site
|
|
can back up the others, such that failures at one site, including
|
|
something like deleting all the sources, can be recovered from. Thus
|
|
the sites need not trust each other as much as for many shared
|
|
databases, and the system may be resilient to many types of
|
|
organizational failures. Sometimes I call this design the
|
|
"CVScluster" design.
|
|
|
|
* Another approach is a master/slave one. Checkins happen at the
|
|
master site, and slave sites need to check whether their local
|
|
repository is up to date before relying on its information.
|
|
|
|
* Another approach is to have each site own a particular branch. This
|
|
one is the most tolerant of flaky networks; if checkins happen at each
|
|
site independently there is no particular problem. The big question
|
|
is whether merges happen only manually, as with existing CVS branches,
|
|
or whether there is a feature whereby there are circumstances in which
|
|
merges from one branch to the other happen automatically (for example,
|
|
the case in which the branches have not diverged). This might be a
|
|
legitimate question to ask even quite aside from multisite features.
|
|
|
|
One additional random tidbit is to note that Eric Raymond has some
|
|
interest in this sort of thing. The item "Cooperative distributed
|
|
freeware development" on http://www.ccil.org/~esr/ has a very brief
|
|
introduction to what he is thinking about.
|
|
|
|
187. Might want to separate out usage error messages and help
|
|
messages. The problem now is that if you specify an invalid option,
|
|
for example, the error message is lost among all the help text. In
|
|
the new regime, the error message would be followed by a one-line
|
|
message directing people to the appropriate help option ("cvs -H
|
|
<command>" or "cvs --help-commands" or whatever, according to the
|
|
situation). I'm not sure whether this change would be controversial
|
|
(as defined in HACKING), so there might be a need for further
|
|
discussion or other actions other than just coding.
|
|
|
|
188. Option parsing and .cvsrc has at least one notable limitation.
|
|
If you want to set a global option only for some CVS commands, there
|
|
is no way to do it (for example, if one wants to set -q only for
|
|
"rdiff"). I am told that the "popt" package from RPM
|
|
(http://www.rpm.org) could solve this and other problems (for example,
|
|
if the syntax of option stuff in .cvsrc is similar to RPM, that would
|
|
be great from a user point of view). It would at least be worth a
|
|
look (it also provides a cleaner API than getopt_long).
|
|
|
|
Another issue which may or may not be related is the issue of
|
|
overriding .cvsrc from the command line. The cleanest solution might
|
|
be to have options in mutually exclusive sets (-l/-R being a current
|
|
example, but --foo/--no-foo is a better way to name such options). Or
|
|
perhaps there is some better solution.
|
|
|
|
189. Renaming files and directories is a frequently discussed topic.
|
|
|
|
Some of the problems with the status quo:
|
|
|
|
a. "cvs annotate" cannot operate on both the old and new files in a
|
|
single run. You need to run it twice, once for the new name and once
|
|
for the old name.
|
|
|
|
b. "cvs diff" (or "cvs diff -N") shows a rename as a removal of the
|
|
old file and an addition of the new one. Some people would like to
|
|
see the differences between the file contents (but then how would we
|
|
indicate the fact that the file has been renamed? Certainly the
|
|
notion that "patch(1)" has of renames is as a removal and addition).
|
|
|
|
c. "cvs log" should be able to show the changes between two
|
|
tags/dates, even in the presence of adds/removes/renames (I'm not sure
|
|
what the status quo is on this; see also item #182).
|
|
|
|
d. Renaming directories is way too hard.
|
|
|
|
Implementations:
|
|
|
|
It is perhaps premature to try to design implementation details
|
|
without answering some of the above questions about desired behaviors
|
|
but several general implementations get mentioned.
|
|
|
|
i. No fundamental changes (for example, a "cvs rename" command which
|
|
operated on directories could still implement the current recommended
|
|
practice for renaming directories, which is to rename each of the
|
|
files contained therein via an add and a remove). One thing to note
|
|
that the status quo gets right is proper merges, even with adds and
|
|
removals (Well, mostly right at least. There are a *LOT* of different
|
|
cases; see the testsuite for some of them).
|
|
|
|
ii. Rename database. In this scheme the files in the repository
|
|
would have some arbitrary name, and then a separate rename database
|
|
would indicate the current correspondence between the filename in the
|
|
working directory and the actual storage. As far as I know this has
|
|
never been designed in detail for CVS.
|
|
|
|
iii. A modest change in which the RCS files would contain some
|
|
information such as "renamed from X" or "renamed to Y". That is, this
|
|
would be generally similar to the log messages which are suggested
|
|
when one renames via an add and a removal, but would be
|
|
computer-parseable. I don't think anyone has tried to flesh out any
|
|
details here either.
|
|
|
|
It is interesting to note that in solution ii. version numbers in the
|
|
"new file" start where the "old file" left off, while in solutions
|
|
i. and iii., version numbers restart from 1.1 each time a file is
|
|
renamed. Except perhaps in the case where we rename a file from foo
|
|
to bar and then back to foo. I'll shut up now.
|
|
|
|
Regardless of the method we choose, we need to address how renames
|
|
affect existing CVS behaviors. For example, what happens when you
|
|
rename a file on a branch but not the trunk and then try to merge the
|
|
two? What happens when you rename a file on one branch and delete it
|
|
on another and try to merge the two?
|
|
|
|
Ideally, we'd come up with a way to parameterize the problem and
|
|
simply write up a lookup table to determine the correct behavior.
|
|
|
|
190. The meaning of the -q and -Q global options is very ad hoc;
|
|
there is no clear definition of which messages are suppressed by them
|
|
and which are not. Here is a classification of the current meanings
|
|
of -q; I don't know whether anyone has done a similar investigation of
|
|
-Q:
|
|
|
|
a. The "warm fuzzies" printed upon entering each directory (for
|
|
example, "cvs update: Updating sdir"). The need for these messages
|
|
may be decreased now that most of CVS uses ->fullname instead of
|
|
->file in messages (a project which is *still* not 100% complete,
|
|
alas). However, the issue of whether CVS can offer status as it
|
|
runs is an important one. Of course from the command line it is
|
|
hard to do this well and one ends up with options like -q. But
|
|
think about emacs, jCVS, or other environments which could flash you
|
|
the latest status line so you can see whether the system is working
|
|
or stuck.
|
|
|
|
b. Other cases where the message just offers information (rather
|
|
than an error) and might be considered unnecessarily verbose. These
|
|
have a certain point to them, although it isn't really clear whether
|
|
it should be the same option as the warm fuzzies or whether it is
|
|
worth the conceptual hair:
|
|
|
|
add.c: scheduling %s `%s' for addition (may be an issue)
|
|
modules.c: %s %s: Executing '%s' (I can see how that might be noise,
|
|
but...)
|
|
remove.c: scheduling `%s' for removal (analogous to the add.c one)
|
|
update.c: Checking out %s (hmm, that message is a bit on the noisy side...)
|
|
(but the similar message in annotate is not affected by -q).
|
|
|
|
c. Suppressing various error messages. This is almost surely
|
|
bogus.
|
|
|
|
commit.c: failed to remove tag `%s' from `%s' (Questionable.
|
|
Rationale might be that we already printed another message
|
|
elsewhere but why would it be necessary to avoid
|
|
the extra message in such an uncommon case?)
|
|
commit.c: failed to commit dead revision for `%s' (likewise)
|
|
remove.c: file `%s' still in working directory (see below about rm
|
|
-f analogy)
|
|
remove.c: nothing known about `%s' (looks dubious to me, especially in
|
|
the case where the user specified it explicitly).
|
|
remove.c: removed `%s' (seems like an obscure enough case that I fail
|
|
to see the appeal of being cryptically concise here).
|
|
remove.c: file `%s' already scheduled for removal (now it is starting
|
|
to look analogous to the infamous rm -f option).
|
|
rtag.c: cannot find tag `%s' in `%s' (more rm -f like behavior)
|
|
rtag.c: failed to remove tag `%s' from `%s' (ditto)
|
|
tag.c: failed to remove tag %s from %s (see above about whether RCS_*
|
|
has already printed an error message).
|
|
tag.c: couldn't tag added but un-commited file `%s' (more rm -f
|
|
like behavior)
|
|
tag.c: skipping removed but un-commited file `%s' (ditto)
|
|
tag.c: cannot find revision control file for `%s' (ditto, but at first
|
|
glance seems even worse, as this would seem to be a "can't happen"
|
|
condition)
|
|
|
|
191. Storing RCS files, especially binary files, takes rather more
|
|
space than it could, typically.
|
|
- The virtue of the status quo is that it is simple to implement.
|
|
Of course it is also simplest in terms of dealing with compatibility.
|
|
- Just storing the revisions as separate gzipped files is a common
|
|
technique. It also is pretty simple (no new algorithms, CVS
|
|
already has zlib around). Of course for some files (such as files
|
|
which are already compressed) the gzip step won't help, but
|
|
something which can at least sometimes avoid rewriting the entire
|
|
RCS file for each new revision would, I would think, be a big
|
|
speedup for large files.
|
|
- Josh MacDonald has written a tool called xdelta which produces
|
|
differences (that is, sufficient information to transform the old
|
|
to the new) which looks for common sequences of bytes, like RCS
|
|
currently does, but which is not based on lines. This seems to do
|
|
quite well for some kinds of files (e.g. FrameMaker documents,
|
|
text files), and not as well for others (anything which is already
|
|
compressed, executables). xdelta 1.10 also is faster than GNU diff.
|
|
- Karl Fogel has thought some about using a difference technique
|
|
analogous to fractal compression (see the comp.compression FAQ for
|
|
more on fractal compression, including at least one patent to
|
|
watch for; I don't know how analogous Karl's ideas are to the
|
|
techniques described there).
|
|
- Quite possibly want some documented interface by which a site can
|
|
plug in their choice of external difference programs (with the
|
|
ability to choose the program based on filename, magic numbers,
|
|
or some such).
|
|
|
|
192. "cvs update" using an absolute pathname does not work if the
|
|
working directory is not a CVS-controlled directory with the correct
|
|
CVSROOT. For example, the following will fail:
|
|
|
|
cd /tmp
|
|
cvs -d /repos co foo
|
|
cd /
|
|
cvs update /tmp/foo
|
|
|
|
It is possible to read the CVSROOT from the administrative files in
|
|
the directory specified by the absolute pathname argument to update.
|
|
In that case, the last command above would be equivalent to:
|
|
|
|
cd /tmp/foo
|
|
cvs update .
|
|
|
|
This can be problematic, however, if we ask CVS to update two
|
|
directories with different CVSROOTs. Currently, CVS has no way of
|
|
changing CVSROOT mid-stream. Consider the following:
|
|
|
|
cd /tmp
|
|
cvs -d /repos1 co foo
|
|
cvs -d /repos2 co bar
|
|
cd /
|
|
cvs update /tmp/foo /tmp/bar
|
|
|
|
To make that example work, we need to think hard about:
|
|
|
|
- where and when CVSROOT-related variables get set
|
|
- who caches said variables for later use
|
|
- how the remote protocol should be extended to handle sending a new
|
|
repository mid-stream
|
|
- how the client should maintain connections to a variety of servers
|
|
in a single invocation.
|
|
|
|
Because those issues are hairy, I suspect that having a change in
|
|
CVSROOT be an error would be a better move.
|
|
|
|
193. The client relies on timestamps to figure out whether a file is
|
|
(maybe) modified. If something goes awry, then it ends up sending
|
|
entire files to the server to be checked, and this can be quite slow
|
|
especially over a slow network. A couple of things that can happen:
|
|
(a) other programs, like make, use timestamps, so one ends up needing
|
|
to do "touch foo" and otherwise messing with timestamps, (b) changing
|
|
the timezone offset (e.g. summer vs. winter or moving a machine)
|
|
should work on unix, but there may be problems with non-unix.
|
|
|
|
Possible solutions:
|
|
|
|
a. Store a checksum for each file in CVS/Entries or some such
|
|
place. What to do about hash collisions is interesting: using a
|
|
checksum, like MD5, large enough to "never" have collisions
|
|
probably works in practice (of course, if there is a collision then
|
|
all hell breaks loose because that code path was not tested, but
|
|
given the tiny, tiny probability of that I suppose this is only an
|
|
aesthetic issue).
|
|
|
|
b. I'm not thinking of others, except storing the whole file in
|
|
CVS/Base, and I'm sure using twice the disk space would be
|
|
unpopular.
|
|
|
|
194. CVS does not separate the "metadata" from the actual revision
|
|
history; it stores them both in the RCS files. Metadata means tags
|
|
and header information such as the number of the head revision.
|
|
Storing the metadata separately could speed up "cvs tag" enormously,
|
|
which is a big problem for large repositories. It could also probably
|
|
make CVS's locking much less in the way (see comment in do_recursion
|
|
about "two-pass design").
|
|
|
|
195. Many people using CVS over a slow link are interested in whether
|
|
the remote protocol could be any more efficient with network
|
|
bandwidth. This item is about one aspect of that--how the server
|
|
sends a new version of a file the client has a different version of,
|
|
or vice versa.
|
|
|
|
a. Cases in which the status quo already sends a diff. For most text
|
|
files, this is probably already close to optimal. For binary files,
|
|
and anomalous (?) text files (e.g. those in which it would help to do
|
|
moves, as well as adds and deletes), it might be worth looking into other
|
|
difference algorithms (see item #191).
|
|
|
|
b. Cases in which the status quo does not send a diff (e.g. "cvs
|
|
commit").
|
|
|
|
b1. With some frequency, people suggest rsync or a similar algorithm
|
|
(see ftp://samba.anu.edu.au/pub/rsync/). This could speed things up,
|
|
and in some ways involves the most minimal changes to the default CVS
|
|
paradigm. There are some downsides though: (1) there is an extra
|
|
network turnaround, (2) the algorithm needs to transmit some data to
|
|
discover what difference type programs can discover locally (although
|
|
this is only about 1% of the size of the files).
|
|
|
|
b2. If one is willing to require that users use "cvs edit" before
|
|
editing a file on the client side (in some cases, a development
|
|
environment like emacs can make this fairly easy), then the Modified
|
|
request in the protocol could be extended to allow the client to just
|
|
send differences instead of entire files. In the degenerate case
|
|
(e.g. "cvs diff" without arguments) the required network traffic is
|
|
reduced to zero, and the client need not even contact the server.
|
|
|
|
196. Using a CVSROOT with a trailing slash will confuse CVS. I think
|
|
we need to add a call to strip_trailing_slashes in root.c
|
|
(parse_cvsroot), but I haven't considered all of the ramifications.
|