[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20637: incompatible, undocumented change to vc-working-revision

From: Dmitry Gutov
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Sun, 10 Apr 2016 19:00:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 04/10/2016 11:00 AM, Michael Albinus wrote:

If there is a simple and obvious fix for this problem, let apply it to
the emacs-25 branch. Even if we must change it later in master.

Why not revert 7f9b037245ddb662ad98685e429a2498ae6b7c62? I believe I've mentioned that suggestion before.

The only difficulty here, as far as I'm concerned, is to update the corresponding tests so they don't break, but are not disabled, and still look somewhat reasonable. That's where the merge conflict concerns come into play. But "no disabled tests" is not a hard requirement for release anyway.

But I doubt that's possible. This bug report was written on 23 May 2015,
it was marked as release blocker on the same day, and still no fix.

Not because it's too difficult to resolve.

For all those problems in vc I have the impression, that we must
stabilize vc first. Starting with the very basic functionality - that's
why I've added tests for vc-backend and vc-responsible-backend.

I agree with the sentiment, but not with certain choices of the areas to "stabilize" it in. You've basically been discovering aspects of the current commands and functions that are poorly specified. But those aspects (with some exceptions, I suppose) are not regressions from Emacs 24. They have been there for a while.

I don't care whether we discuss it here, in bug#19548 or in the
emacs-devel ML.

I don't mind too much any way, but 19548 is for the manual and such. A separate bug report (or several) or discussions on emacs-devel seem preferable. Unless I'm mistaken about these problems being orthogonal, of course.

The docstring says nothing about directories, so the call I've applied
is legal.

Best wishes to whoever wrote that docstring.

... I even doubt that directories are out of scope of vc-backend.
Directories can be registered for some VCS, for example for CVS, or for
ClearCase which I use at work (I know, we have no official support for
ClearCase in vc).

In general, VC supports the lowest common denominator across the backends. Or at least, a feature should be supported in a few important ones. CVS is on its way out, and ClearCase is a relatively niche tool.

Anyway, the point is VC is for people to be able to write code depending on the public API and see it work across many VCSes. And Git and Mercurial, at least, don't track directories.

Therefore we shall precise the docstring of
vc-backend, that it returns the backend also for directories for VCSes
which support rgistration of directories.

Why? Just tell anyone who wants to know a directory's backend to use vc-responsible-backend instead.

I know what the docstring says :-) My question is, whether we shall
offer the same argument list for both vc-backend and vc-responsible-backend.

We could, but honestly, that question doesn't sound particularly important right now. Yes, it's a wart, and if there are no users that pass a list to it, we can remove this possibility.

Note that vc-backend and vc-responsible-backend have different performance characteristics (and, I imagine, different behavior in case of nested repositories), so simply replacing all uses of the former with the latter is not a good idea.

Don't know. But I believe "interactively" is not the criterion whether a
general vc function shall exist. I also don't call vc-registered interactively.

Interactive use would be a strong justification. vc-register can be used interactively, and it's called from vc-next-action.

How will we use vc-unregister?

It should call
  common code, like vc-file-clearprops. For the time being, I have
  emulated this.

Are you doing that just to test the `unregister' implementations?


That seems very low priority. I wonder how often vc-transfer-file gets used in practice these days.

And I'm still in favor of adding vc-unregister in vc.el.

I don't really mind.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]