From: Dmitry Gutov <dgutov@yandex.ru>
To: "Eric S. Raymond" <esr@thyrsus.com>
Cc: emacs-devel@gnu.org
Subject: Re: My plans for VC mode
Date: Sat, 22 Nov 2014 16:33:19 +0200 [thread overview]
Message-ID: <86r3wvb900.fsf@yandex.ru> (raw)
In-Reply-To: <20141122133351.46279382C23@snark.thyrsus.com> (unknown@unknown.invalid's message of "Sat, 22 Nov 2014 08:33:50 -0500 (EST)")
Hi Eric,
> Accordingly, I have concluded that it is time to chuck backward
> compatibility and rewrite tha back-end API, simplifying as radically
> as I can and enforcing much stricter separation between the VC upper
> layer and the back ends.
Here's hoping it won't be a full rewrite. Aside from serving as a
plumbing for a set of commands, VC is a helpful VCS-agnostic (to a
certain degree) wrapper over a set of commands which third-party
packages can use.
http://elpa.gnu.org/packages/diff-hl.html, for example, uses `vc-state',
as well as `diff', `dir-status' and `dir-status-files', and relies on
their current semantics (even if they're a bit broken in certain
implementations; I intend to improve that).
> While I do branching I'm also going to look at removing the elaborate
> caching the older back ends use to avoid disk traffic as much as
> possible. That made sense when I first wrote it twenty-odd years
> ago, but it's been a chronic source of TOCTOU bugs and other
> coherency problems ever since. Disks are much faster now; it's
> probably time for the state-heuristic stuff to die.
Not exactly sure which functions you're referring to here, but an
example of a function in a "newer" backend that uses caching is
`vc-git-root'.
Correctness should trump performance most of the time, but there are
still traffic-sensitive workflows out there, such as TRAMP.
next prev parent reply other threads:[~2014-11-22 14:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-22 13:33 My plans for VC mode Unknown
2014-11-22 14:17 ` Jan D.
2014-11-22 16:29 ` Eric S. Raymond
2014-11-22 16:44 ` Jan D.
2014-11-22 14:33 ` Dmitry Gutov [this message]
2014-11-22 16:37 ` Eric S. Raymond
2014-11-22 17:46 ` Dmitry Gutov
2014-11-22 18:08 ` Eric S. Raymond
2014-11-23 1:27 ` Dmitry Gutov
2014-11-22 22:32 ` Stefan Monnier
2014-11-23 1:01 ` Dmitry Gutov
2014-11-23 6:25 ` Eric S. Raymond
2014-11-22 23:17 ` Steinar Bang
2014-11-23 20:02 ` Eric S. Raymond
2014-11-23 20:11 ` Eli Zaretskii
2014-11-22 16:11 ` Stefan Monnier
2014-11-22 16:41 ` Eric S. Raymond
2014-11-22 16:59 ` Dieter Deyke
2014-11-22 22:34 ` Stefan Monnier
2014-11-23 19:58 ` Eric S. Raymond
2014-11-24 6:40 ` Dieter Deyke
2014-11-24 7:50 ` Eric S. Raymond
2014-11-24 7:55 ` Kan-Ru Chen (陳侃如)
2014-11-24 8:07 ` Eric S. Raymond
2014-11-24 14:33 ` Stefan Monnier
2014-11-24 17:57 ` Eric S. Raymond
2014-11-23 19:27 ` Ivan Shmakov
2014-11-23 20:10 ` Eric S. Raymond
2014-11-22 19:02 ` Michael Albinus
2014-11-23 6:26 ` Eric S. Raymond
2014-11-23 8:23 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r3wvb900.fsf@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=esr@thyrsus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.