From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: vc-find-revision-no-save? Date: Tue, 31 Jan 2023 06:57:31 -0500 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38986"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Dmitry Gutov , Philip Kaludercic , Stefan Monnier , Stefan Kangas , schwab@linux-m68k.org, Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 31 12:58:23 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMpHK-0009zx-SN for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Jan 2023 12:58:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMpGn-00056G-3b; Tue, 31 Jan 2023 06:57:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMpGl-0004zs-RL for emacs-devel@gnu.org; Tue, 31 Jan 2023 06:57:47 -0500 Original-Received: from mail-ej1-f51.google.com ([209.85.218.51]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pMpGj-0003MM-QB for emacs-devel@gnu.org; Tue, 31 Jan 2023 06:57:47 -0500 Original-Received: by mail-ej1-f51.google.com with SMTP id hx15so21319346ejc.11 for ; Tue, 31 Jan 2023 03:57:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=msAtCHZhXEROUkfAvSQwuAV/v0ioCV04wsIt95NogwQ=; b=FRZeb4vuUfTqXYDa1qBujTSUMBqC/1wY0Brj0KHyVnKoZpg1ZjVNgRyTJKUr23BSH2 dGAjs1Xbu1jBYV7n9yBMeIh5RQwCRq64q3MpklfD5lku9AGCQOANAyHkrNKHAIpWgxeI rqjR1iHEB17dqQtrmB8IpNPKH5yzK6426ep5mfKPb7emcEDaELCI26Ut/dJyV3cE7cYH 9a3/KMSVkDHkFizkAuzqp5YCpiEWy1MyW4Ckp2MkPDsUesoVW5anA3oZ5wUinqyD/FrD w8+cp9PA0Zyz+7rBZG3F8HWNaNNQtQyLEiHIlJIk9vu/wjDD/w3l2vcn+ymdRyBR2pzk H99g== X-Gm-Message-State: AFqh2kp3FNYE9sdqj2y5b+iT1VjpTNvEvb/vuLapiMMKmQ8/GH/FyV2I 4TIXUnRbP5FpqYGpCqJ3D1rwYNWprxUh7bUTwcg= X-Google-Smtp-Source: AMrXdXtEPDf4LyBCWw400S+ixsURHn8b5udWaMnBkdxdOoCf3sEq80MJx+Y+Xd24WxqjLxg2M1GwOtZJh2DRDnQdh14= X-Received: by 2002:a17:906:a00b:b0:7c0:beef:79e2 with SMTP id p11-20020a170906a00b00b007c0beef79e2mr10087729ejy.148.1675166263357; Tue, 31 Jan 2023 03:57:43 -0800 (PST) Received-SPF: pass client-ip=209.85.218.51; envelope-from=john.yates.sheets@gmail.com; helo=mail-ej1-f51.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302824 Archived-At: Towards the end of Oct 2022, each of you contributed to the above named emacs-devel email thread. With issue #61071 on debbugs.gnu.org, I have attempted to address some of the points mentioned in the email thread via: [PATCH 1/3] Refactor and document vc-find-revision caching I append the cover letter and commit message below. This is my very first attempt to contribute to Emacs. So far I have received no feedback. If I am doing something wrong, please let me know. /john =3D=3D [PATCH 0/3] Cover letter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This is a series of three bisectable (I hope :-) patches, culminating in support of a new Emacs backup scheme: * [PATCH 1/3] Refactor and document vc-find-revision caching * [PATCH 2/3] Introduce VC timemachine capability * [PATCH 3/3] Introduce vc-bos: backup on save (to an RCS file) This Backup-On-Save scheme exploits a file system mirror scheme introduced in the first patch. By exploiting a little known aspect of RCS's algorithm for locating a master file, backups are stored completely removed from the work file (i.e. no local RCS directories) and under exactly the same filename (i.e. no ',v' suffix or similar). Accessing backed-ups exploits a new vc-timemachine capability, introduced in the second patch. Both the design and code owe much to Peter Stiernstr=C3=B6m's original git-timemachine.el. To sidestep any copyright issues, Peter has graciously assigned git-timemachine.el's copyright to the FSF. With the submission timemachine functionality is available in both vc-git and vc-rcs. This backup scheme works equaly well with files already under some VCS as well as with files that are not currently version controlled. For me (primarily a C++ programmer) this is: * My first significant bit of elisp * My first exposure to the VC codebase * My first Emacs / FSF submission I welcome all nature of feedback: * Code criticism * Violations of pertinent standards * Bug reports * Suggested improvement * . . . =3D=3D [PATCH 1/3] Refactor and document vc-find-revision caching =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Previously there existed two helper functions for vc--revision-other-window= : * vc--revision-other-window-save * vc--revision-other-window-no-save The expectation seems to have been that when materializing a revision is deemed costly (slow backend? remote? ...) it should be saved. I believe that, even though the word 'cache' is never used, this was intended to be a caching mechanism. That said, the logic provided only a single save/no-save global toggle. Aspects of this mechanism were discussed in this email thread: https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01794.html I have tried to address some of the concerns raised therein and to provide some clearer abstractions: * When a revision gets saved it is deemed a cache. Thus it is imperative that the cached revision be protected and adequately validated before being reused. * A cached revision may be saved as a sibling of the file that triggered it= s materialization or in may be saved in a mirror directory tree rooted at `vc-cache-root'. The latter choice avoids cluttering work trees with wit= h historic revisions and enables caching across work trees. `vc-cache-root= ' will also provide a location for the forthcoming vc-bos's backups. * I have defined the concept of a revision buffer. This is the form of buffer returned by vc's find-revision operation. It is bound to a specific revision, it is read-only and it has a nil buffer-file-name. Thus it visits no saved nor cached file. The rationale is twofold: - A revision is a materialization of immutable history - The only potential value for a revision buffer's buffer-file-name is a cache file which should likewise be regarded as immutable. Futher, if materializing revisions is not deemed costly, even that file may not exist. So, in the interest of consistency, revision buffers do not visit files. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * lisp/vc/vc.el (vc-find-revision-no-save, vc-find-revision-cache): Rename defcustoms to be more descriptive. (vc-find-revision, vc-find-revision-save, vc-find-revision-no-save): Reimplement the enssence of these three function as a single `vc-find-revision' function. Clarify that the result is a revision buffer, unattached to any file. Support optional caching, either alongside the original file or within a mirror directory structure beneath `vc-cache-root'.