From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: New VC mode -- review request Date: Thu, 04 Oct 2007 09:18:58 +0200 Message-ID: <874ph7xs7x.fsf@ambire.localdomain> References: <20071003103501.GA4997@thyrsus.com> <200710031431.l93EVfFZ021233@oogie-boogie.ics.uci.edu> <20071003170048.GB7014@thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1191495359 18119 80.91.229.12 (4 Oct 2007 10:55:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Oct 2007 10:55:59 +0000 (UTC) Cc: Dan Nicolaescu , emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 04 12:55:55 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IdOMy-00017R-T9 for ged-emacs-devel@m.gmane.org; Thu, 04 Oct 2007 12:55:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IdOMu-0004Dv-Ed for ged-emacs-devel@m.gmane.org; Thu, 04 Oct 2007 06:55:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IdOMq-0004Ch-9P for emacs-devel@gnu.org; Thu, 04 Oct 2007 06:55:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IdOMn-0004AH-F1 for emacs-devel@gnu.org; Thu, 04 Oct 2007 06:55:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IdOMn-0004A3-5p for emacs-devel@gnu.org; Thu, 04 Oct 2007 06:55:41 -0400 Original-Received: from ppp-56-36.21-151.libero.it ([151.21.36.56] helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IdOMm-0001Ai-6i for emacs-devel@gnu.org; Thu, 04 Oct 2007 06:55:40 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1IdKz4-0002fy-K7; Thu, 04 Oct 2007 09:18:58 +0200 In-Reply-To: <20071003170048.GB7014@thyrsus.com> (Eric S. Raymond's message of "Wed\, 3 Oct 2007 13\:00\:48 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:80231 Archived-At: () "Eric S. Raymond" () Wed, 3 Oct 2007 13:00:48 -0400 Dan Nicolaescu : > > vc-rollback = C-x v c > > Do you have an implementation for this function for any > backend? It would be interesting to see it. There is one for SCCS in old VC if you want to look at it. I think I at one point implemented it for one other backend, but the code and concept were so dodgy that I decided it was best shot through the head. here is the implementation i use for cvs: (defun ttn-cvs-cancel-version (file editable) "Undo the most recent checkin of FILE then do \"cvs update\". EDITABLE non-nil means do \"cvs edit\" afterwards." (unless (and (stringp vc-mode) (string= " CVS-" (substring vc-mode 0 5))) (error "File locally modified, aborting")) (let ((rev (substring vc-mode 5))) (vc-cvs-command nil 0 file "admin" (concat "-o" rev)) (vc-cvs-command nil 0 file "update") (when editable (vc-cvs-command nil 0 file "edit")))) (defun ttn-cvs-rollback (files) ;; Usage: (defalias 'vc-cvs-rollback 'ttn-cvs-rollback) "Undo the most recent checkin of FILE then do \"cvs update\"." (ttn-cvs-cancel-version (car files) nil)) although rollback and cancel-version, before that, are shunned, i find them useful for lone-programmer (ttn-only) situations where admin/recovery overhead for mistakes is tolerable. i think we should provide them but continue to urge their avoidance for shared-repo situations, however. the "we don't provide it because you shouldn't do that" tone has always bothered me gutterally. thi