Hmm... doesn't that mean that:
cvs edit myfile.h
[change myfile.h]
cvs unedit myfile.h
cvs ci -mtest myfile.h
Would cause changes to be checked in?
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
--
You can lead a horticulture, but you can't make her think.
-- Janis Joplin, when asked to use the word "horticulture" in a sentence
Noel L Yap wrote:
> 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
