hardenedbsd/HardenedBSD
1
0
Fork 0
mirror of https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git synced 2024-12-27 21:44:34 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
06d8715958
HardenedBSD/gnu/usr.bin/cvs/TODO

611 lines
28 KiB
Plaintext
Raw Blame History

$CVSid: @(#)TODO 1.26 94/09/21 $
01. testing. An automated testing enviroment would be a big win.
14. Pathname stripper, for checkout, as well as for writing the
Repository file.
[[ I have a simple one, but need to make sure to call it at all the
appropriate points ]]
16. List of current users of a directory needs to be maintained.
[[ sort of solved by history database ]]
22. Catch signals for cleanup when "add"ing files.
24. Insist on a log message.
30. Add "patch" program option to the modules database.
31. Think hard about ^C recovery.
35. Add "admin" command as an interface to "rcs".
[[ a cheesy version is there, but it should be re-done ]]
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 allowing parallel source trees that can easily track
each other.
[[ sort of solved with the automagic branch support, but I want more ]]
45. Consider enhancing the "patch" and "tag" command support in the module
database -- they seem hard to use since these commands deal directly
with the RCS ,v files.
46. Perhaps checkout/checkin/tag/patch commands should be imbedded in the
file system directly, using special known command names?
49. cvs xxx commands should be able to deal with files in other
directories. I want to do a cvs ci foo/bar.c. This complicates things
a bit because one might specify files in different directories, but you
could just bucket sort them and do everything for each directory
together. Other than that, it's just a matter of using the adm
directory from the directory containing the file rather than the cwd.
[[ most commands now use the generic recursion processor, but not all;
this note is left here to remind me to fix the others ]]
51. a way to identify what files other people are working on. Imagine "cvs
modified", which prints out a table like
file modifiers
===== =========
foo.c
bar.c wsd
baz.c nrt jda
I think this would be pretty difficult; I don't know if this
information is stored anywhere. Also it's hard to say how one gets a
user name, maybe a path to their local hierarchy is all you could get.
[[ the history stuff does some of this, but not all ]]
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.
53. I'd suggest a way to notify users if/when a file(s) is being worked on.
I suggest:
+ Always checkout/update files a readonly.
+ To work on a file, the user should do:
cvs advise filename
+ This would maintain their email address associated with that
file name in the repository and change the file mode to writable.
+ If other references to that file exist, the registered individuals
are notified via email that another user(s) is going to be working
on same.
+ When a committ occurs, the user is automatically 'unadvise'd (the
inverse command should be supported as well) and other's are notified
that a merge will be necessary before their checkin can be
successful.
56. There should be a .cvsrc file that is sourced to customize various
variables. Perhaps there should be a system-wide .cvsrc file that is
sourced, then the one in one's home directory, then the environment
variables are checked for overriding values.
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.
64. Need to greatly increase the performance of an initial checkout.
[[ it got better, then we added functionality, making it worse again ]]
66. Length of the CVS temporary files must be limited to 14 characters for
System-V stupid support. As weel as the length on the CVS.adm files.
67. cvs import should populate the vendor sources with CVS.adm files so
that one could use the vendor sources directly without having the check
them out.
69. Consider enhacing import to add a module automatically to the module
database. Perhaps with a new option, or perhaps with an editor.
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.
74. Consider adding a way to remove directories/files that you are done
with... somehow.
[[ cvs release sort of does this ]]
76. Consider adding a layer of abstraction so that CVS can work with both
RCS and SCCS files. Larry says this should be #ifdef'ed.
79. Might be nice to have some sort of interface to TFS 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. Add revision controlled symbolic links to CVS using one of the tag
fields in the RCS file.
87. Consider renaming directories and files.
88. Consider using mmap to read files on Sun systems and using a smaller
buffer to read files on other systems. A patch has been supplied.
89. Study the new Dick Grune version of CVS and port any new interesting
features to my version of CVS.
91. Better document the format of the source repository and how one might
convert their current SCCS or RCS files into CVS format.
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.
94. Need to think hard about remote source control and environments
together.
[[ a contributor has this working over Internet TCP links! ]]
97. Think about some way to undo a change. This looks hard given the
current framework of CVS.
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.
106. Need to figure out how to delete and rename directories from a release
and yet have old releases still be accessible.
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?
112. When merging in changes (Glist) and the file ends up exactly as the
RCS revision, an "M" is displayed as the "cvs update" output. This
should really just be a "U". Just an optimization.
113. The "cvs update" command should tee its output to a log file in ".".
114. I wanted to check in my metapreen code tonight, which I had put into
a new file called preen.c. So, recalling your excellent instructions,
I typed "cvs add preen.c". However, cvs complained that there was
already a preen.c in /master/etc/fsck/Attic and therefore it wouldn't
take mine. Now what?
115. I still think "cvs modules" is a good idea.
Since everything else is inside cvs, "mkmodules" should be in there too:
Add a "modules" (synonym "mod") command directly in cvs.
("checkout -c" is not really intuitive. I'd move it into "mod -s".)
"mod" Print database as typed. (line count as record id?)
"mod -s" Print the sorted database (as "checkout -c" does now)
"mod -m" Internal replacement for "mkmodules" command.
"mod module ..." Print the raw dbm record for the named modules
"mod -p module ..." Print relative filenames contained in modules.(no ",v")
"mod -l module ..." Prints more info about relative filenames ("ls -l"?)
"mod -f file ..." Tells you what module(s) the filenames are in.
116. The first thing import did was to complain about a missing CVSROOT.adm.
How about having "import()" copy some "CVSROOT.adm/{loginfo,modules}"
templates into place if it discovers none pointed to by $CVSROOT? As it
stands, one has to hand-craft them. It would be real nice to have it
happen automatically.
[[ I hope to add a "cvsinit" command to the installation instructions ]]
119. Consider an option to have import checkout the RCS or SCCS files
if necessary.
122. If Name_Repository fails, it currently causes CVS to die completely. It
should instead return NULL and have the caller do something reasonable.
123. Add a flag to import to not build vendor branches for local code.
124. Anyway, I thought you might want to add something like the following
to the cvs and mkmodules 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.
128. When I tag a file, the message tells me that I'm tagging a directory.
129. Something strange seems to have happened here. When I check this out,
the update lines (U CFTS/...) seem to report a bogus leading CFTS
(e.g. U CFTS/Medusa_TS/...) when the later files are checked out.
The directory structure doesn't seem to be botched, just the
messages. I don't recall seeing this before.
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.
135. The email CVS sends with each checkin, should include the version
number of each file it is checking in.
[[ Sort of solved by contrib/log.pl, which does a good job of this ]]
136. Is it possible to specify a command to be run on each file when it is
checked out and another command to be run before it is checked in?
My idea of how this feature would be used:
On checkout:
run indent with user's preferred style
On checkin:
run indent with space-saving, style-free for checkin
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.
139. murf@dingus.sps.mot.com (Steve Murphy) suggests adding a mode where
CVS can work across e-mail to a single repository located at some
"known" mail address. The update/commit operations would work through
email aliases, causing them to be slow, but would work nonetheless.
This could allow for very cheap remote development sites.
[[ We may get to TCP connections over the Internet for the next
release, but probably won't do an e-mail linkup right away ]]
141. Import should accept modules as its directory argument.
143. Update the documentation to show that the source repository is
something far away from the files that you work on.
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.
148. It would be nice if cvs import (and perhaps commit when the rcs file
is created) would set the comment leader automagically to the prefix
string of $Log entry, if some option is given. For example, if a file
has a line `%*&# $Log...' the comment leader would be set to `%*&# '.
It would help a lot for unknown files with unknown suffix, and if the
comment leader is not standard. Perhaps for cvs 1.4.
149. On Sun, 2 Feb 92 22:01:38 EST, rouilj@dl5000.bc.edu (John P. Rouillard)
said:
Maybe there should be an option to cvs admin that allows a user to
change the Repository 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.
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 msg 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.
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 trag -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.
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. This could easily be done by adding an option to mkmodules
to perform the verification.
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.
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.
157. The "cvs release" command does not understand about module names with
the same flexibility that the "checkout" and "rdiff" commands do.
It should, though, since it's confusing right now.
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.
159. On "update", when a merge is done, CVS should remember that your file
was merged into and should keep reminding you of this fact until you
actually look at the file (change its access time). Once you do this,
it should go back to being a normal, unmodified file. This way, after
a big update, you can run update again to see which files just got
merged and may need attention.
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.
161. The date parser included with CVS (lib/getdate.y) does not support
such RCS-supported dates as "1992/03/07". It probably should.
162. We have had a number of cases where some idiot does a "cd" into $CVSROOT
and tries to run checkout. I suggest you make it impossible for someone
to check out anything directly into $CVSROOT. This works (though there
is no error checking):
getwd(curdir);
chdir(getenv("CVSROOT"));
getwd(cvsrootdir);
strcat(cvsrootdir, "/");
chdir(curdir);
if (!strncmp (curdir, cvsrootdir, strlen(cvsrootdir))) {
abort with a nasty message about writing into the repository.
}
(In other words, if the real path where $CVSROOT is stored is a parent of
the real pathname of your current directory, die horribly.)
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.
164. The rcsinfo file should be able to expand environment variables to
find the pathname to the template file. Perhaps it should just
popen("cat <line>"); and read the resulting output, to let the shell
do the dirty work.
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
167. "cvs log" doesn't understand about CVS magic branch numbers. As such,
the command:
cvs log -r1.63.2
cvs log -rC2
where "C2" is a magic branch that resolves to 1.63.2 do not print the
same things. Sigh.
168. After making changes to a set of files, some of which were in
sub-directories, I wanted to build a patch file for the whole works:
cvs diff -c -rPROD-REL .
However, any diffs for files in sub-directories did not have relative
pathnames. For example, with local changes to perl's hints/aix_rs.sh:
===================================================================
RCS file: /local/src-CVS/misc/perl/hints/aix_rs.sh,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 aix_rs.sh
*** 1.1.1.1 1992/12/17 19:43:32
--- aix_rs.sh 1993/01/05 21:33:12
***************
*** 1,3 ****
It was easy enough to fix in this case, but I'd suggest that the file
name have the relative directory prepended and a proper patch "Index:"
line be added, such as this:
===================================================================
RCS file: /local/src-CVS/misc/perl/hints/aix_rs.sh,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 hints/aix_rs.sh
Index: hints/aix_rs.sh
*** 1.1.1.1 1992/12/17 19:43:32
--- hints/aix_rs.sh 1993/01/05 21:33:12
***************
*** 1,3 ****
169. We are using CVS as the configuration control for a software reuse library.
What we do is do system calls passing the needed arguments. In the next
release, it would be nice to see an option to put cvs .o files into a
archive library with an API. This enhancement would go nicely with the
notion of being able to integrate tools into a large software engineering
environment.
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.
171. We have been actively using CVS since September, and we still have the
opinion that automerge is dangerous. We have been burned by it a
couple of times so far, when people missed the notification of a
conflict during an update, and then they committed the files with the
>>>>>>> and <<<<<<< reports in them. This kind of problem usually gets
noticed before commit in compiled files when the compiler croaks, but
we also maintain many documentation files in CVS, and in one case the
problem was not noticed until months later.
172. "cvs add foo/bar" doesn't work, but "cvs remove foo/bar" works. Maybe
"cvs add" should be rewritten to use the recursive directory code that
most of CVS uses.
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.
178. At our site we tag all releases of the sw with
product name and version number, the tag is pretty
long and if you by accident write an old tag which
was in use on an old release, the default behaviour
of cvs is to change the old tag!!!
Could the CVS system reject to reuse an old tag?
You have the possibility to manually remove it,
but you will not have to be afraid of one tag
silently changing.
179. "cvs admin" does not log its actions with loginfo, nor does it check
whether the action is allowed with commitinfo. It should.
Reference in New Issue View Git Blame Copy Permalink