From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Disabling VC: Documentation seems inadequate. Date: Thu, 4 Dec 2003 12:46:21 +0000 (GMT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <1070485372.15753.126.camel@localhost> Reply-To: Alan Mackenzie NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1070544384 14080 80.91.224.253 (4 Dec 2003 13:26:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 13:26:24 +0000 (UTC) Cc: Andre Spiegel Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 14:26:17 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARtUn-0005XS-00 for ; Thu, 04 Dec 2003 14:26:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARtUn-0007uX-00 for ; Thu, 04 Dec 2003 14:26:17 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARu0n-0004Rz-Jh for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 08:59:21 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARu0R-0004RQ-NL for emacs-devel@gnu.org; Thu, 04 Dec 2003 08:58:59 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARtzu-0004Jo-MD for emacs-devel@gnu.org; Thu, 04 Dec 2003 08:58:57 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARtnk-0001c8-Ve; Thu, 04 Dec 2003 08:45:53 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id MAA00254; Thu, 4 Dec 2003 12:46:22 GMT X-Sender: root@acm.acm Original-To: emacs-devel@gnu.org In-Reply-To: <1070485372.15753.126.camel@localhost> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18362 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18362 On Wed, 3 Dec 2003, Andre Spiegel wrote: >On Wed, 2003-12-03 at 21:45, Alan Mackenzie wrote: >> I think files.texi should be amended so that it explicitly states how >> to disable VC. The attached patch does just this. >Sorry for making it less clear than it should have been. Thanks for the >patch, I'll install it. Thanks! [ .... ] >Just out of curiosity, what was the reason you wanted to disable VC >completely? Perhaps there was an annoyance or a misunderstanding that >should be considered. For me, editing files and version control are distinct activities. I do all my CVSing from the command line, and prefer it this way. I feel more in control. I get very emotional about this topic, and I'm not sure why. I think I've got hangups from some very restrictive commercial VC system I had to use a long time ago. Several times in the past I've done C-x C-q to make a buffer read only (simply to stop me changing it by accident) and found to my dismay that the file got checked in, or got error messages "can't access repository". That such an innocent operation, toggling read-onliness, could trigger such a drastic action (checking a file in/out) took me aback, somewhat. Sometimes (at work rather than at play) I've just wanted, say, to reindent somebody else's messy code temporarily (to be able to understand it), typed C-x C-q to make the buffer writeable, and been hit with the file being checked out. I mentioned this in summer of 2002, and you took on the task of polling users on the issue of what C-x C-q should do (thanks!). It turned out that my feeling wasn't that widespread - it was my problem. So, of course, I bound C-x C-q to `toggle-read-only' in my own .emacs. But even so, in the last few weeks: (i) Sometimes my files (checked out from SourceForge under CVS control), get loaded into RO buffers, despite the files being writeable. I haven't investigated why; (ii) Sometimes Emacs has signalled an error on C-x C-s. This occurred on Emacs 21.1, but seems to have been fixed for 21.3. It happened after I'd edited a buffer, then renamed the file to a "backup" name (e.g. mv cc-awk.el cc-awk.191103.el) before doing C-x C-s; (I used mv rather than cp so as to preserve the file's timestamp). Now this is all probably "pilot error", but it's hassle which appears not to bring me any benefit. The basic notions about VC don't match the way I hack software (I think I'm talking more about VC systems which use locks rather than CVS). I often want to change a file _without_ checking it out - to play with it, to see what it looks like with comments added, to test an alternative algorithm, that sort of thing, but without impeding colleagues or leaving the (public copy of the) file in un unstable state. Having decided that a change is good, THEN is the time to check the file out, make the changes permanent, and check it in. Emacs's VC tries to prevent me doing things this way (if I've understood it properly). Sometimes I want to set a _file_ RO without it getting checked in. In short, the copies of the source I have on my hard disk should be MY personal copy, to play around with as I wish, unless I _explicitly_ request an update from the repository or commit changes to it. I have no problem with other people wanting Emacs's VC to steer them through the processes, though. A particularly bad thing once happened to me on a proprietary VC system. I had made some experimental changes (after being "forced" to check out the file first). A colleague needed to change that file in a hurry, so I clicked the "undo lock" button in a dialog box to give him the file. To my anger, that fascist VC system wiped out my changes (without asking me first) in the process of returning the lock. Now it's quite likely that my personal process for hacking code is somewhat unusual, but surely Emacs exists for unusual people. ;-) Emacs VC appears to hinder me personally without offering me any help. This is why I want to disable it. -- Alan Mackenzie (Munich, Germany) acm@muc.de