From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andre Spiegel Newsgroups: gmane.emacs.devel Subject: Re: Disabling VC: Documentation seems inadequate. Date: Fri, 05 Dec 2003 18:07:59 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1070644078.626.29.camel@localhost> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1070644425 4147 80.91.224.253 (5 Dec 2003 17:13:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2003 17:13:45 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 05 18:13:42 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 1ASJWQ-0000lF-00 for ; Fri, 05 Dec 2003 18:13:42 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ASJWP-0007fN-00 for ; Fri, 05 Dec 2003 18:13:41 +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 1ASKPQ-0007iD-6c for emacs-devel@quimby.gnus.org; Fri, 05 Dec 2003 13:10:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ASKPK-0007gU-Uy for emacs-devel@gnu.org; Fri, 05 Dec 2003 13:10:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ASKOo-0007KY-Le for emacs-devel@gnu.org; Fri, 05 Dec 2003 13:10:25 -0500 Original-Received: from [193.113.160.16] (helo=mail.o2.co.uk) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ASKOo-0007KK-4Q for emacs-devel@gnu.org; Fri, 05 Dec 2003 13:09:54 -0500 Original-Received: from [217.235.21.56] (217.235.21.56) by mail.o2.co.uk (7.0.020) (authenticated as 01792247376@o2online.de) id 3FCF8F4000063F52; Fri, 5 Dec 2003 17:07:59 +0000 Original-To: Alan Mackenzie In-Reply-To: X-Mailer: Ximian Evolution 1.4.5 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:18425 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18425 On Thu, 2003-12-04 at 13:46, Alan Mackenzie wrote: > 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. The results were rather inconclusive -- there were strong advocates of either position, both with very good reasons. Based on this, RMS decided salomonically that we should remove the version control meaning of C-x C-q by default (users can rebind the key individually). So this concerns of yours has really been fully addressed (as Stefan already pointed out). The change is in Emacs CVS. > (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). That would definitely be bugs if it were reproducible. Please don't hesitate to report them as such if you can find a reproducible sequence of actions that triggers that behaviour. > 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. That's a very reasonable way to work and it is the natural approach for "modern" systems like CVS (along with the notion that locking really isn't necessary if developers have their own private workspace). Also, VC is no longer that intrusive even for systems with locking, believe me :-). Just the other day, I was consulting for a software development team at a bank and introduced them to RCS (they were hesitant to use CVS because they thought that they must absolutely have locks). But when they tried, it took them 15 seconds to override RCS' locking mechanism and bring the file permissions into an inconsistent state and cause really unpleasant effects. After that, they decided that maybe CVS was the better way to go, after all :-) Hoping that you might someday turn on VC again :-) Andre