I can't help you with the first part of the request, but I have been planning on
working the second part.
"cvs -Q release -d" will force the removal of everything except when there are
files that have been "cvs edit"'ed and modified. Currently, there's no way
around the interactiveness of "cvs unedit" (which "cvs release" eventually
does). I've been planning on fixing this part of "cvs edit"/"cvs unedit". My
proposal is to have "cvs edit" create a backup of the file (via the usual
methods) and "cvs unedit" not to unmodify the file. This way, the sole
responsibility of "cvs unedit" would be to notify watchers about the action.
Of course, I haven't started on this patch yet, but I do expect it to be my next
CVS TODO (I might have something within a couple of months).
Noel
[EMAIL PROTECTED] on 2000.03.31 18:03:06
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: "cvs release" wishlist
Greetings!
When our build tool recognizes that someone has removed a CVS module from a
build area, I had planned to "cvs release -d $module" to remove it from the
build area and then do a "make clean" everywhere to make sure I had a clean
build area.
I was bummed to find out that 'cvs release' doesn't take a module definition,
but a DIRECTORY. I would think if I could checkout a module, I would be able
to remove a module. Even better, a "-f" option to force the removal even if
there are locally-modified files would make this whole thing much more
automatable.
Does this sound reasonable? Possible? Desirable?
:)hal mahaffey
