Commit | Line | Data |
---|---|---|
d304b67d WJ |
1 | @(#)TODO 1.22 92/04/10 |
2 | ||
3 | 14. Pathname stripper, for checkout, as well as for writing the | |
4 | Repository file. | |
5 | [[ I have a simple one, but need to make sure to call it at all the | |
6 | appropriate points ]] | |
7 | ||
8 | 16. List of current users of a directory needs to be maintained. | |
9 | [[ sort of solved by history database ]] | |
10 | ||
11 | 22. Catch signals for cleanup when "add"ing files. | |
12 | ||
13 | 24. Insist on a log message. | |
14 | ||
15 | 30. Add "patch" program option to the modules database. | |
16 | ||
17 | 31. Think hard about ^C recovery. | |
18 | ||
19 | 35. Add "admin" command as an interface to "rcs". | |
20 | [[ a cheesy version is there, but it should be re-done ]] | |
21 | ||
22 | 38. Think hard about using RCS state information to allow one to checkin | |
23 | a new vendor release without having it be accessed until it has been | |
24 | integrated into the local changes. | |
25 | ||
26 | 39. Think about allowing parallel source trees that can easily track | |
27 | each other. | |
28 | [[ sort of solved with the automagic branch support, but I want more ]] | |
29 | ||
30 | 45. Consider enhancing the "patch" and "tag" command support in the module | |
31 | database -- they seem hard to use since these commands deal directly | |
32 | with the RCS ,v files. | |
33 | ||
34 | 46. Perhaps checkout/checkin/tag/patch commands should be imbedded in the | |
35 | file system directly, using special known command names? | |
36 | ||
37 | 49. cvs xxx commands should be able to deal with files in other | |
38 | directories. I want to do a cvs ci foo/bar.c. This complicates things | |
39 | a bit because one might specify files in different directories, but you | |
40 | could just bucket sort them and do everything for each directory | |
41 | together. Other than that, it's just a matter of using the adm | |
42 | directory from the directory containing the file rather than the cwd. | |
43 | [[ most commands now use the generic recursion processor, but not all; | |
44 | this note is left here to remind me to fix the others ]] | |
45 | ||
46 | 51. a way to identify what files other people are working on. Imagine "cvs | |
47 | modified", which prints out a table like | |
48 | ||
49 | file modifiers | |
50 | ===== ========= | |
51 | foo.c | |
52 | bar.c wsd | |
53 | baz.c nrt jda | |
54 | ||
55 | I think this would be pretty difficult; I don't know if this | |
56 | information is stored anywhere. Also it's hard to say how one gets a | |
57 | user name, maybe a path to their local hierarchy is all you could get. | |
58 | [[ the history stuff does some of this, but not all ]] | |
59 | ||
60 | 52. SCCS has a feature that I would *love* to see in CVS, as it is very | |
61 | useful. One may make a private copy of SCCS suid to a particular user, | |
62 | so other users in the authentication list may check files in and out of | |
63 | a project directory without mucking about with groups. Is there any | |
64 | plan to provide a similar functionality to CVS? Our site (and, I'd | |
65 | imagine, many other sites with large user bases) has decided against | |
66 | having the user-groups feature of unix available to the users, due to | |
67 | perceived administrative, technical and performance headaches. A tool | |
68 | such as CVS with features that provide group-like functionality would | |
69 | be a huge help. | |
70 | ||
71 | 53. I'd suggest a way to notify users if/when a file(s) is being worked on. | |
72 | I suggest: | |
73 | + Always checkout/update files a readonly. | |
74 | + To work on a file, the user should do: | |
75 | cvs advise filename | |
76 | + This would maintain their email address associated with that | |
77 | file name in the repository and change the file mode to writable. | |
78 | + If other references to that file exist, the registered individuals | |
79 | are notified via email that another user(s) is going to be working | |
80 | on same. | |
81 | + When a committ occurs, the user is automatically 'unadvise'd (the | |
82 | inverse command should be supported as well) and other's are notified | |
83 | that a merge will be necessary before their checkin can be | |
84 | successful. | |
85 | ||
86 | 56. There should be a .cvsrc file that is sourced to customize various | |
87 | variables. Perhaps there should be a system-wide .cvsrc file that is | |
88 | sourced, then the one in one's home directory, then the environment | |
89 | variables are checked for overriding values. | |
90 | ||
91 | 62. Consider using revision controlled files and directories to handle the | |
92 | new module format -- consider a cvs command front-end to | |
93 | add/delete/modify module contents, maybe. | |
94 | ||
95 | 63. The "import" and vendor support commands (co -j) need to be documented | |
96 | better. | |
97 | ||
98 | 64. Need to greatly increase the performance of an initial checkout. | |
99 | [[ it got better, then we added functionality, making it worse again ]] | |
100 | ||
101 | 66. Length of the CVS temporary files must be limited to 14 characters for | |
102 | System-V stupid support. As weel as the length on the CVS.adm files. | |
103 | ||
104 | 67. cvs import should populate the vendor sources with CVS.adm files so | |
105 | that one could use the vendor sources directly without having the check | |
106 | them out. | |
107 | ||
108 | 69. Consider enhacing import to add a module automatically to the module | |
109 | database. Perhaps with a new option, or perhaps with an editor. | |
110 | ||
111 | 72. Consider re-design of the module -o, -i, -t options to use the file | |
112 | system more intuitively. | |
113 | ||
114 | 73. Consider an option (in .cvsrc?) to automatically add files that are new | |
115 | and specified to commit. | |
116 | ||
117 | 74. Consider adding a way to remove directories/files that you are done | |
118 | with... somehow. | |
119 | [[ cvs release sort of does this ]] | |
120 | ||
121 | 76. Consider adding a layer of abstraction so that CVS can work with both | |
122 | RCS and SCCS files. Larry says this should be #ifdef'ed. | |
123 | ||
124 | 79. Might be nice to have some sort of interface to TFS and tagged | |
125 | revisions. | |
126 | ||
127 | 82. Maybe the import stuff should allow an arbitrary revision to be | |
128 | specified. | |
129 | ||
130 | 84. Improve the documentation about administration of the repository and | |
131 | how to add/remove files and the use of symbolic links. | |
132 | ||
133 | 85. Add revision controlled symbolic links to CVS using one of the tag | |
134 | fields in the RCS file. | |
135 | ||
136 | 87. Consider renaming directories and files. | |
137 | ||
138 | 88. Consider using mmap to read files on Sun systems and using a smaller | |
139 | buffer to read files on other systems. A patch has been supplied. | |
140 | ||
141 | 89. Study the new Dick Grune version of CVS and port any new interesting | |
142 | features to my version of CVS. | |
143 | ||
144 | 91. Better document the format of the source repository and how one might | |
145 | convert their current SCCS or RCS files into CVS format. | |
146 | ||
147 | 92. Look into this: | |
148 | After a bit of soul searching via dbx, I realized my sin was that I'd | |
149 | specified "echo" as the program to call from loginfo. The commit | |
150 | procedure worked fine till it hit my echo, then silently aborted | |
151 | leaving the lockfiles intact. Since I needn't use the loginfo | |
152 | facility, I simply removed those commands and it all works. | |
153 | ||
154 | 93. Need to think hard about release and development environments. Think | |
155 | about execsets as well. | |
156 | ||
157 | 94. Need to think hard about remote source control and environments | |
158 | together. | |
159 | [[ a contributor has this working over Internet TCP links! ]] | |
160 | ||
161 | 97. Think about some way to undo a change. This looks hard given the | |
162 | current framework of CVS. | |
163 | ||
164 | 98. If diff3 bombs out (too many differences) cvs then thinks that the file | |
165 | has been updated and is OK to be commited even though the file | |
166 | has not yet been merged. | |
167 | ||
168 | 100. Checked out files should have revision control support. Maybe. | |
169 | ||
170 | 102. Perhaps directory modes should be propagated on all import check-ins. | |
171 | Not necessarily uid/gid changes. | |
172 | ||
173 | 103. setuid/setgid on files is suspect. | |
174 | ||
175 | 104. cvs should recover nicely on unreadable files/directories. | |
176 | ||
177 | 105. cvs should have administrative tools to allow for changing permissions | |
178 | and modes and what not. | |
179 | ||
180 | 106. Need to figure out how to delete and rename directories from a release | |
181 | and yet have old releases still be accessible. | |
182 | ||
183 | 107. It should be possible to specify a list of symbolic revisions to | |
184 | checkout such that the list is processed in reverse order looking for | |
185 | matches within the RCS file for the symbolic revision. If there is | |
186 | not a match, the next symbolic rev on the list is checked, and so on, | |
187 | until all symbolic revs are exhausted. This would allow one to, say, | |
188 | checkout "4.0" + "4.0.3" + "4.0.3Patch1" + "4.0.3Patch2" to get the | |
189 | most recent 4.x stuff. This is usually handled by just specifying the | |
190 | right release_tag, but most people forget to do this. | |
191 | ||
192 | 108. If someone creates a whole new directory (i.e. adds it to the cvs | |
193 | repository) and you happen to have a directory in your source farm by | |
194 | the same name, when you do your cvs update -d it SILENTLY does | |
195 | *nothing* to that directory. At least, I think it was silent; | |
196 | certainly, it did *not* abort my cvs update, as it would have if the | |
197 | same thing had happened with a file instead of a directory. | |
198 | ||
199 | 109. I had gotten pieces of the sys directory in the past but not a | |
200 | complete tree. I just did something like: | |
201 | ||
202 | cvs get * | |
203 | ||
204 | Where sys was in * and got the message | |
205 | ||
206 | cvs get: Executing 'sys/tools/make_links sys' | |
207 | sh: sys/tools/make_links: not found | |
208 | ||
209 | I suspect this is because I didn't have the file in question, | |
210 | but I do not understand how I could fool it into getting an | |
211 | error. I think a later cvs get sys seemed to work so perhaps | |
212 | something is amiss in handling multiple arguments to cvs get? | |
213 | ||
214 | 112. When merging in changes (Glist) and the file ends up exactly as the | |
215 | RCS revision, an "M" is displayed as the "cvs update" output. This | |
216 | should really just be a "U". Just an optimization. | |
217 | ||
218 | 113. The "cvs update" command should tee its output to a log file in ".". | |
219 | ||
220 | 114. I wanted to check in my metapreen code tonight, which I had put into | |
221 | a new file called preen.c. So, recalling your excellent instructions, | |
222 | I typed "cvs add preen.c". However, cvs complained that there was | |
223 | already a preen.c in /master/etc/fsck/Attic and therefore it wouldn't | |
224 | take mine. Now what? | |
225 | ||
226 | 115. I still think "cvs modules" is a good idea. | |
227 | Since everything else is inside cvs, "mkmodules" should be in there too: | |
228 | ||
229 | Add a "modules" (synonym "mod") command directly in cvs. | |
230 | ("checkout -c" is not really intuitive. I'd move it into "mod -s".) | |
231 | ||
232 | "mod" Print database as typed. (line count as record id?) | |
233 | "mod -s" Print the sorted database (as "checkout -c" does now) | |
234 | "mod -m" Internal replacement for "mkmodules" command. | |
235 | "mod module ..." Print the raw dbm record for the named modules | |
236 | "mod -p module ..." Print relative filenames contained in modules.(no ",v") | |
237 | "mod -l module ..." Prints more info about relative filenames ("ls -l"?) | |
238 | "mod -f file ..." Tells you what module(s) the filenames are in. | |
239 | ||
240 | 116. The first thing import did was to complain about a missing CVSROOT.adm. | |
241 | How about having "import()" copy some "CVSROOT.adm/{loginfo,modules}" | |
242 | templates into place if it discovers none pointed to by $CVSROOT? As it | |
243 | stands, one has to hand-craft them. It would be real nice to have it | |
244 | happen automatically. | |
245 | [[ I hope to add a "cvsinit" command to the installation instructions ]] | |
246 | ||
247 | 119. Consider an option to have import checkout the RCS or SCCS files | |
248 | if necessary. | |
249 | ||
250 | 122. If Name_Repository fails, it currently causes CVS to die completely. It | |
251 | should instead return NULL and have the caller do something reasonable. | |
252 | ||
253 | 123. Add a flag to import to not build vendor branches for local code. | |
254 | ||
255 | 124. Anyway, I thought you might want to add something like the following | |
256 | to the cvs and mkmodules man pages: | |
257 | ||
258 | BUGS | |
259 | The sum of the sizes of a module key and its contents are | |
260 | limited. See ndbm(3). | |
261 | ||
262 | 126. Do an analysis to see if CVS is forgetting to close file descriptors. | |
263 | Especially when committing many files (more than the open file limit | |
264 | for the particular UNIX). | |
265 | ||
266 | 127. Look at *info files; they should all be quiet if the files are not | |
267 | there. Should be able to point at a RCS directory and go. | |
268 | ||
269 | 128. When I tag a file, the message tells me that I'm tagging a directory. | |
270 | ||
271 | 129. Something strange seems to have happened here. When I check this out, | |
272 | the update lines (U CFTS/...) seem to report a bogus leading CFTS | |
273 | (e.g. U CFTS/Medusa_TS/...) when the later files are checked out. | |
274 | ||
275 | The directory structure doesn't seem to be botched, just the | |
276 | messages. I don't recall seeing this before. | |
277 | ||
278 | 130. cvs diff with no -r arguments does not need to look up the current RCS | |
279 | version number since it only cares about what's in the Entries file. | |
280 | This should make it much faster. | |
281 | ||
282 | It should ParseEntries itself and access the entries list much like | |
283 | Version_TS does (sticky tags and sticky options may need to be | |
284 | supported here as well). Then it should only diff the things that | |
285 | have the wrong time stamp (the ones that look modified). | |
286 | ||
287 | 134. Make a statement about using hard NFS mounts to your source | |
288 | repository. Look into checking NULL fgets() returns with ferror() to | |
289 | see if an error had occurred. | |
290 | ||
291 | 135. The email CVS sends with each checkin, should include the version | |
292 | number of each file it is checking in. | |
293 | [[ Sort of solved by contrib/log.pl, which does a good job of this ]] | |
294 | ||
295 | 136. Is it possible to specify a command to be run on each file when it is | |
296 | checked out and another command to be run before it is checked in? | |
297 | My idea of how this feature would be used: | |
298 | On checkout: | |
299 | run indent with user's preferred style | |
300 | On checkin: | |
301 | run indent with space-saving, style-free for checkin | |
302 | ||
303 | 137. Some sites might want CVS to fsync() the RCS ,v file to protect | |
304 | against nasty hardware errors. There is a slight performance hit with | |
305 | doing so, though, so it should be configurable in the .cvsrc file. | |
306 | Also, along with this, we should look at the places where CVS itself | |
307 | could be a little more synchronous so as not to lose data. | |
308 | [[ I've done some of this, but it could use much more ]] | |
309 | ||
310 | 138. Some people have suggested that CVS use a VPATH-like environment | |
311 | variable to limit the amount of sources that need to be duplicated for | |
312 | sites with giant source trees and no disk space. | |
313 | ||
314 | 139. murf@dingus.sps.mot.com (Steve Murphy) suggests adding a mode where | |
315 | CVS can work across e-mail to a single repository located at some | |
316 | "known" mail address. The update/commit operations would work through | |
317 | email aliases, causing them to be slow, but would work nonetheless. | |
318 | This could allow for very cheap remote development sites. | |
319 | [[ We may get to TCP connections over the Internet for the next | |
320 | release, but probably won't do an e-mail linkup right away ]] | |
321 | ||
322 | 141. Import should accept modules as its directory argument. | |
323 | ||
324 | 143. Update the documentation to show that the source repository is | |
325 | something far away from the files that you work on. | |
326 | ||
327 | 144. Have cvs checkout look for the environment variable CVSPREFIX | |
328 | (or CVSMODPREFIX or some such). If it's set, then when looking | |
329 | up an alias in the modules database, first look it up with the | |
330 | value of CVSPREFIX attached, and then look for the alias itself. | |
331 | This would be useful when you have several projects in a single | |
332 | repository. You could have aliases abc_src and xyz_src and | |
333 | tell people working on project abc to put "setenv CVSPREFIX abc_" | |
334 | in their .cshrc file (or equivalent for other shells). | |
335 | Then they could do "cvs co src" to get a copy of their src | |
336 | directory, not xyz's. (This should create a directory called | |
337 | src, not abc_src.) | |
338 | ||
339 | 145. After you create revision 1.1.1.1 in the previous scenario, if | |
340 | you do "cvs update -r1 filename" you get revision 1.1, not | |
341 | 1.1.1.1. It would be nice to get the later revision. Again, | |
342 | this restriction comes from RCS and is probably hard to | |
343 | change in CVS. Sigh. | |
344 | ||
345 | |"cvs update -r1 filename" does not tell RCS to follow any branches. CVS | |
346 | |tries to be consistent with RCS in this fashion, so I would not change | |
347 | |this. Within CVS we do have the flexibility of extending things, like | |
348 | |making a revision of the form "-r1HEAD" find the most recent revision | |
349 | |(branch or not) with a "1." prefix in the RCS file. This would get what | |
350 | |you want maybe. | |
351 | ||
352 | This would be very useful. Though I would prefer an option | |
353 | such as "-v1" rather than "-r1HEAD". This option might be | |
354 | used quite often. | |
355 | ||
356 | 146. The merging of files should be controlled via a hook so that programs | |
357 | other than "rcsmerge" can be used, like Sun's filemerge or emacs's | |
358 | emerge.el. | |
359 | ||
360 | 148. It would be nice if cvs import (and perhaps commit when the rcs file | |
361 | is created) would set the comment leader automagically to the prefix | |
362 | string of $Log entry, if some option is given. For example, if a file | |
363 | has a line `%*&# $Log...' the comment leader would be set to `%*&# '. | |
364 | It would help a lot for unknown files with unknown suffix, and if the | |
365 | comment leader is not standard. Perhaps for cvs 1.4. | |
366 | ||
367 | 149. On Sun, 2 Feb 92 22:01:38 EST, rouilj@dl5000.bc.edu (John P. Rouillard) | |
368 | said: | |
369 | Maybe there should be an option to cvs admin that allows a user to | |
370 | change the Repository file with some degree of error checking? | |
371 | Something like "cvs admin reposmv /old/path /new/pretty/path". Before | |
372 | it does the replace it check to see that the files | |
373 | /new/pretty/path/<dir>/<files> exist. | |
374 | ||
375 | 150. I have a customer request for a way to specify log message per | |
376 | file, non-interactively before the commit, such that a single, fully | |
377 | recursive commit prompts for one commit message, and concatenates the | |
378 | per file messages for each file. In short, one commit, one editor | |
379 | session, log messages allowed to vary across files within the commit. | |
380 | Also, the per file messages should be allowed to be written when the | |
381 | files are changed, which may predate the commit considerably. | |
382 | ||
383 | A new command seems appropriate for this. The state can be saved in the | |
384 | CVS directory. I.e., | |
385 | ||
386 | % cvs msg foo.c | |
387 | Enter log message for foo.c | |
388 | >> fixed an uninitialized variable | |
389 | >> ^D | |
390 | ||
391 | The text is saved as CVS/foo.c,m (or some such name) and commit is | |
392 | modified to append (prepend?) the text (if found) to the log message | |
393 | specified at commit time. Easy enough. | |
394 | ||
395 | 151. Also, is there a flag I am missing that allows replacing Ulrtx_Build | |
396 | by Ultrix_build? I.E. I would like a tag replacement to be a one step | |
397 | operation rather than a two step "cvs rtag -r Ulrtx_Build Ultrix_Build" | |
398 | followed by "cvs trag -d Ulrtx_Build" | |
399 | ||
400 | 152. The "cvs -n" option does not work as one would expect for all the | |
401 | commands. In particular, for "commit" and "import", where one would | |
402 | also like to see what it would do, without actually doing anything. | |
403 | ||
404 | 153. There should be some command (maybe I just haven't figured | |
405 | out which one...) to import a source directory which is already | |
406 | RCS-administered without losing all prior RCS gathered data. Thus, it | |
407 | would have to examine the RCS files and choose a starting version and | |
408 | branch higher than previous ones used. | |
409 | ||
410 | 154. When committing the modules file, a pre-commit check should be done to | |
411 | verify the validity of the new modules file before allowing it to be | |
412 | committed. This could easily be done by adding an option to mkmodules | |
413 | to perform the verification. | |
414 | ||
415 | 155. The options for "cvs history" are mutually exclusive, even though | |
416 | useful queries can be done if they are not, as in specifying both a | |
417 | module and a tag. A workaround is to specify the module, then run the | |
418 | output through grep to only display lines that begin with T, which are | |
419 | tag lines. | |
420 | ||
421 | 156. Also, how hard would it be to allow continuation lines in the | |
422 | {commit,rcs,log}info files? It would probably be useful with all of | |
423 | the various flags that are now available, or if somebody has a lot of | |
424 | files to put into a module. | |
425 | ||
426 | 157. The "cvs release" command does not understand about module names with | |
427 | the same flexibility that the "checkout" and "rdiff" commands do. | |
428 | It should, though, since it's confusing right now. | |
429 | ||
430 | 158. If I do a recursive commit and find that the same RCS file is checked | |
431 | out (and modified!) in two different places within my checked-out | |
432 | files (but within the realm of a single "commit"), CVS will commit the | |
433 | first change, then overwrite that change with the second change. We | |
434 | should catch this (typically unusual) case and issue an appropriate | |
435 | diagnostic and die. | |
436 | ||
437 | 159. On "update", when a merge is done, CVS should remember that your file | |
438 | was merged into and should keep reminding you of this fact until you | |
439 | actually look at the file (change its access time). Once you do this, | |
440 | it should go back to being a normal, unmodified file. This way, after | |
441 | a big update, you can run update again to see which files just got | |
442 | merged and may need attention. | |
443 | ||
444 | 160. The checks that the commit command does should be extended to make | |
445 | sure that the revision that we will lock is not already locked by | |
446 | someone else. Maybe it should also lock the new revision if the old | |
447 | revision was already locked by the user as well, thus moving the lock | |
448 | forward after the commit. | |
449 | ||
450 | 161. The date parser included with CVS (lib/getdate.y) does not support | |
451 | such RCS-supported dates as "1992/03/07". It probably should. | |
452 | ||
453 | 162. We have had a number of cases where some idiot does a "cd" into $CVSROOT | |
454 | and tries to run checkout. I suggest you make it impossible for someone | |
455 | to check out anything directly into $CVSROOT. This works (though there | |
456 | is no error checking): | |
457 | ||
458 | getwd(curdir); | |
459 | chdir(getenv("CVSROOT")); | |
460 | getwd(cvsrootdir); | |
461 | strcat(cvsrootdir, "/"); | |
462 | chdir(curdir); | |
463 | ||
464 | if (!strncmp (curdir, cvsrootdir, strlen(cvsrootdir))) { | |
465 | abort with a nasty message about writing into the repository. | |
466 | } | |
467 | ||
468 | (In other words, if the real path where $CVSROOT is stored is a parent of | |
469 | the real pathname of your current directory, die horribly.) | |
470 | ||
471 | 163. The rtag/tag commands should have an option that removes the specified | |
472 | tag from any file that is in the attic. This allows one to re-use a | |
473 | tag (like "Mon", "Tue", ...) all the time and still have it tag the | |
474 | real main-line code. | |
475 | ||
476 | 164. The rcsinfo file should be able to expand environment variables to | |
477 | find the pathname to the template file. Perhaps it should just | |
478 | popen("cat <line>"); and read the resulting output, to let the shell | |
479 | do the dirty work. | |
480 |