From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juliusz Chroboczek Newsgroups: gmane.emacs.devel Subject: Limitations of Emacs' vc when using modern backends Date: Thu, 15 Dec 2005 02:42:04 +0100 Message-ID: <7i8xunt9ub.fsf@lanthane.pps.jussieu.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1134611060 26441 80.91.229.2 (15 Dec 2005 01:44:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Dec 2005 01:44:20 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 15 02:44:10 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Emi8V-0006vY-J6 for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2005 02:42:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emi97-0002YG-Vt for ged-emacs-devel@m.gmane.org; Wed, 14 Dec 2005 20:43:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Emi8y-0002Xz-VY for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:42:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Emi8x-0002Xn-E5 for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:42:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Emi8x-0002Xk-82 for emacs-devel@gnu.org; Wed, 14 Dec 2005 20:42:51 -0500 Original-Received: from [134.157.0.129] (helo=shiva.jussieu.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EmiB5-0005Jv-R9; Wed, 14 Dec 2005 20:45:04 -0500 Original-Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.13.5/jtpda-5.4) with ESMTP id jBF1g6gg009755 ; Thu, 15 Dec 2005 02:42:06 +0100 (CET) X-Ids: 166 Original-Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (8.13.4/jtpda-5.4) with ESMTP id jBF1g47F028707 ; Thu, 15 Dec 2005 02:42:04 +0100 Original-Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.60) (envelope-from ) id 1Emi8C-0000Tw-Kk; Thu, 15 Dec 2005 02:42:04 +0100 Original-To: Andre Spiegel User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.7.2 (shiva.jussieu.fr [134.157.0.166]); Thu, 15 Dec 2005 02:42:06 +0100 (CET) X-Antivirus: scanned by sophie at shiva.jussieu.fr X-Miltered: at shiva.jussieu.fr with ID 43A0C9EE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! 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:47756 Archived-At: Hi Andre, In short, the problems with vc could be solved by making the following three changes. While I believe that these changes should be fully backwards-compatible, I'm definitely not claiming I know enough about the Emacs release schedule to claim they should be in Emacs 22. 1. It should be possible for a backend to override vc-previous-version. 2. vc-previous-version should take the file name in addition to the revision. 3. vc should call a backend-specific function (say vc-BACKEND-canonical-revision) to normalise a revision name (again, one that takes both a revision and a file name) before creating a buffer. (1) CVS uses a very specific model for numbering revisions; not all systems use sequences of integers that encode a path in an and/or tree. Subversion, for example, uses plain integers, while Darcs, Git and Monotone use opaque tokens (actually SHA1 hashes of something or something else, but that's irrelevant for our discussion). Only the backend can know what the ``previous version'' is. (2) CVS versions files, while modern systems version trees; the effect is that the correct ``previous version'' depends on the file name. To give an example using Subversion, suppose that revision 1 creates files A and B, revision 2 modifies file A, and revision 3 modifies file B. Then vc-darcs-previous-version(3, A) should return 2 (which it already does), but vc-darcs-previous-version(3, B) should return 1. (3) Darcs identifies revisions by a 65-character long hash of a bunch of data, which is not something you want to type. Because of that, vc-darcs allows identifying a revision by a number of different means (see vc-darcs-rev-to-hash if you want the gory details). This means that if you use vc-version-other-window and friends, you'll end up with multiple buffers containing the same revision of a given file. I believe that the functionality of vc-darcs-rev-to-hash (getting a canonical revision identifier for a given revision identifier) should be moved into vc itself, and called whenever vc gets a revision from the user. The default implementation would just be the identity, but it should be possible for a backend to override it. Because of point (2) above, vc-BACKEND-canonical-revision should be able to access the file name in addition to the revision. Thanks for your help, Juliusz Chroboczek P.S. I'm not subscribed to the list -- please CC me with any follow-ups.