Yeah, what's wrong with that? With cvs-1.10.8, "cvs update -C" will give you a
clean copy of the file provided you don't run into any of the merge bugs. If
you do run into those bugs, you can always revert back to the standard "cvs up
-r <base-rev> file >file" to get a clean copy.
Yes, it'll now be two separate steps (one to clean the file, one to unedit the
file). The alternative is to make "cvs unedit" interface more complicated by
giving it three more options (one to check for modification, one to force the
unedit without unmodifying, and one to unedit and unmodify the file). If you
don't like the two step deal, you can always write a wrapper around cvs, but, as
of now, there is absolutely no way (without manually going into the admin files
or kludging a way (eg "cvs edit" the file again)) to unedit a file and keep all
modifications.
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
