GNU bug report logs - #20637
incompatible, undocumented change to vc-working-revision

Previous Next

Full log

Message #28 received at 20637 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 20637 <at> debbugs.gnu.org
Subject: Re: bug#20637: incompatible, undocumented change to
 vc-working-revision
Date: Sun, 10 Apr 2016 19:00:41 +0300

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?
>
> Yes.

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.