The implication being that wanting to keep the file checked out upon unedit is the
desired behavior for the majority of users the majority of the time (otherwise
saving the changes is also only a two step process) or that CVS's defined default
behavior should never contain the possibility of data loss?
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
--
Cynic: n. Someone who smells the flowers and looks for the casket.
Noel L Yap wrote:
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
Noel L Yap wrote:
> 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
