killing a CVS commit

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Liberty Young
Date:  
Subject: killing a CVS commit
On Mon, 2002-12-16 at 13:40, Lynn David Newton wrote:
>
> This may be more a question for a CVS list or a
> sysadmin list, but ... for you CVS users out there,
> particularly any who have ever admin'ed a CVS
> repository:
>
> Does anyone know of a correct or graceful way to kill a
> cvs commit once it's started?
>
> Several times, after updating files, I run cvs commit
> only to find that one or more files I didn't intend to
> commit are included ... and sometimes following through
> with the commit would be a Very Bad Thing, e.g., when
> I've made manure out of what was previously a perfectly
> functional program.
>
> What I've done is this:
>
> o Suspend the editor (I usually use vi for $CVSEDITOR)
> with C-z.
>
> o Run ps to identify and kill the process.
>
> o Go to CVSROOT and delete the lock files and
> directories.
>
> This normally frees things up. On the other hand,
>
> (a) This seems horribly ungraceful and like the Wrong
>     Way to do it.

>
> (b) Completing the commit and then backing out the
>     change seems like an undesireable option as well.

>
> (c) As a side note, it's been brought to my attention
>     that whenever I do this (there have been three or
>     four times in the last couple of weeks), it leaves
>     a vi process spinning wildly out of control, eating
>     up 98% of the CPU time. (This is on an ancient
>     OS/BSD system. I don't know what happens on a Linux
>     system, though I could experiment to find out.)

>
> It's (c) that I particularly want to avoid in the
> future. The lesson is to be careful before running cvs
> commit. After all, that's why they call it "commit",
> right?
>
> All suggestions welcome.
>
> --
> Lynn David Newton
> Phoenix, AZ


I think you've gotten the most important lesson out of it all; be super
carefull before doing commits. One thing you should do before doing a
'cvs commit' is to do 'cvs update'. This will report any conflicts
between your working copy and the master cvs repository (which may have
changed) before you get to the commit stage.
Also, and importantly, it will show you which files a commit will
affect. Watch that list scroll by carefully!

Even though I try to follow some basic steps before doing a cvs commit,
i too realize that I've just screwed up when i'm looking at my vim
editor and the list of files cvs is about to commit. I use the ':q!'
command from within vim, and cvs gives me a prompt asking if i which to
abort, commit with empty log message, or continue. By choosing abort, I
safely avoid the commit process.

You may get different results depending on your cvs client version and
your version of vim. I'm running it all on a Mandrake 8.2 system.