Oh yeah, another view (ie reply) to your question would be: "cvs edit" and
family is meant to be part of a communication medium. "cvs edit" tells others
you are modifying the file and you plan to commit those modification. "cvs
unedit" tells others you've changed your mind and you'll no longer commit those
modification (if any).
Also, I do plan to make yet another patch, "cvs ci -c", that'll check whether
the committer has valid edits on the files to be committed before going through
with the commit. So, in your scenario, if the user did "cvs ci -c -mtest
myfile.h", the commit would abort (of course, for optimal performance the user
really should have "commit -c" in his/her .cvsrc file).
Noel
[EMAIL PROTECTED] on 2000.04.03 20:18:31
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: "cvs release" wishlist
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
