GNU bug report logs - #21383
Static revisions in vc-working-revision

Previous Next

Full log

View this message in rfc822 format

From: Jonathan H <pythonnut <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 21383-done <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#21383: Static revisions in vc-working-revision
Date: Wed, 2 Sep 2015 15:44:01 -0700

[Message part 1 (text/plain, inline)]

Something seems a bit amiss with the current patch.

I'm using (vc-working-revision buffer-file-name (vc-responsible-backend
buffer-file-name)) to determine the current working revision.

As far as I can tell, vc-working-revision will cache the current working
revision in a file property, but it doesn't know when to invalidate the
cache, so the results can be stale. In fact, in the specific case of git,
you probably can't get any faster than a rev-parse anyway, so caching
doesn't make much sense.

I have a sneaking suspicion that git isn't the only backend where this can
happen.

Thanks,
Jonathan



On Wed, Sep 2, 2015 at 3:49 AM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 09/02/2015 06:50 AM, Stefan Monnier wrote:
>
>> Maybe you see it better.  I only imagined the problem limited to the
>>> non-file-granularity backends.
>>>
>>
>> You mean like most current backends? ;-)
>>
>
> Yes. But as long as its only limited to the backends (and can be fixed
> there), as opposed to being inherently present in vc.el, log-edit.el, etc,
> it's less of a problem.
>
> And we can't simply remove the FILE argument in many backend commands: it's
>>> often used for vc-file-get/setprop.
>>>
>>
>> I know.
>>
>> In any case, it's not that bad: it works.  But there's something fishy
>> that will surely bite at some point.  Maybe those FILE args should be
>> redefined to be relative to default-directory (and can't use things like
>> "../..").
>>
>
> vc-file-setprop won't work on a relative path. Or shouldn't, at least.
>
> And are you talking about FILE arg to vc-status, or e.g. vc-git-status? If
> vc-status requires the path to be relative, that will complicate the
> consumer interface (now I have to worry about producing the relative path).
> If vc-status will be responsible for that before calling vc-git-status, it
> won't work in file-granular backends. Anyway, why would we want that extra
> call, even if it's cached?
>
> And vc-git-working-revision won't care if FILE is absolute or relative,
> which is the crux of the problem. I'd rather backends like Git, if we're
> going to fix this, used FILE's parent directory to change default-directory
> temporarily before calling Git.
>

[Message part 2 (text/html, inline)]

Previous Next

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