vc-directory breakage

vc-directory breakage

[Eric S. Raymond]

I apologize for the broken state of vc-directory.  I would not voluntarily
have left it in a bad state, but I had an acute attack of viral 
gastroentritis yesterday.  Unsurprisingly, a hospital emergency room
turns out not to be a good place from which to fix Lisp bugs.

I'm mostly better now and back on the problem. In the present state of
trunk, it should be possible to do a fresh start of start
vc-directory and get the expected behavior.  However, there's some
odd problem with the way vc-dir is setting up its buffer-local
variables that causes a crash if a *vc-dir* buffer already exists.
I'll have a workaround for that shortly; a true fix may take longer.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!

Re: vc-directory breakage

[David Kastrup]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:

> I apologize for the broken state of vc-directory.  I would not
> voluntarily have left it in a bad state, but I had an acute attack of
> viral gastroentritis yesterday.  Unsurprisingly, a hospital emergency
> room turns out not to be a good place from which to fix Lisp bugs.

Actually, that is an argument for a distributed version control system.
Even while one might need to group the work into non-working checkins
for oneself at first, one can reorganize before pushing everything out
to the public repository.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vc-directory breakage

[Bastien Guerry]

David Kastrup <dak@gnu.org> writes:

> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
>
>> I apologize for the broken state of vc-directory.  I would not
>> voluntarily have left it in a bad state, but I had an acute attack of
>> viral gastroentritis yesterday.  Unsurprisingly, a hospital emergency
>> room turns out not to be a good place from which to fix Lisp bugs.
>
> Actually, that is an argument for a distributed version control
> system.

That's also an argument for better wireless connection in hospitals.

But that's also where it's cool to work together: even when you are
completely down with a nasty gastroentritis, you can expect people
to cheer you up by pointing out the positive aspects of all this!

Damned.

-- 
Bastien

Re: vc-directory breakage

[David Kastrup]

Bastien Guerry <bzg@altern.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
>>
>>> I apologize for the broken state of vc-directory.  I would not
>>> voluntarily have left it in a bad state, but I had an acute attack of
>>> viral gastroentritis yesterday.  Unsurprisingly, a hospital emergency
>>> room turns out not to be a good place from which to fix Lisp bugs.
>>
>> Actually, that is an argument for a distributed version control
>> system.
>
> That's also an argument for better wireless connection in hospitals.

With a DVCS, you need no connection at all for a workflow involving
version control.

> But that's also where it's cool to work together: even when you are
> completely down with a nasty gastroentritis, you can expect people to
> cheer you up by pointing out the positive aspects of all this!

There is not much I could say about gastroenteritis that would be
ontopic in emacs-devel.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vc-directory breakage

[Juanma Barranquero]

On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:

>  There is not much I could say about gastroenteritis that would be
>  ontopic in emacs-devel.

"not much" /= "nothing", so I'm dying to know what could you say that
would be ontopic :-)

 Juanma

Re: vc-directory breakage

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:
>
>>  There is not much I could say about gastroenteritis that would be
>>  ontopic in emacs-devel.
>
> "not much" /= "nothing", so I'm dying to know what could you say that
> would be ontopic :-)

That is a risk I am not going to take.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vc-directory breakage

[Bastien Guerry]

David Kastrup <dak@gnu.org> writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:
>>
>>>  There is not much I could say about gastroenteritis that would be
>>>  ontopic in emacs-devel.
>>
>> "not much" /= "nothing", so I'm dying to know what could you say that
>> would be ontopic :-)
>
> That is a risk I am not going to take.

Afraid of being too plethoric?

-- 
Bastien

Re: vc-directory breakage

[David Kastrup]

Bastien Guerry <bzg@altern.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>
>>> On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:
>>>
>>>>  There is not much I could say about gastroenteritis that would be
>>>>  ontopic in emacs-devel.
>>>
>>> "not much" /= "nothing", so I'm dying to know what could you say that
>>> would be ontopic :-)
>>
>> That is a risk I am not going to take.
>
> Afraid of being too plethoric?

No afraid of killing Juanma.  He said that the knowledge could prove
fatal.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vc-directory breakage

[Lennart Borgman (gmail)]

David Kastrup wrote:
> Bastien Guerry <bzg@altern.org> writes:
> 
>> David Kastrup <dak@gnu.org> writes:
>>
>>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>>
>>>> On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:
>>>>
>>>>>  There is not much I could say about gastroenteritis that would be
>>>>>  ontopic in emacs-devel.
>>>> "not much" /= "nothing", so I'm dying to know what could you say that
>>>> would be ontopic :-)
>>> That is a risk I am not going to take.
>> Afraid of being too plethoric?
> 
> No afraid of killing Juanma.  He said that the knowledge could prove
> fatal.

This proves how wrong people are when they say communication here is 
hard and without empathy!

Re: vc-directory breakage

[Bastien Guerry]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> Bastien Guerry <bzg@altern.org> writes:
>>
>>> David Kastrup <dak@gnu.org> writes:
>>>
>>>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>>>>
>>>>> On Mon, May 5, 2008 at 5:45 PM, David Kastrup <dak@gnu.org> wrote:
>>>>>
>>>>>>  There is not much I could say about gastroenteritis that would be
>>>>>>  ontopic in emacs-devel.
>>>>> "not much" /= "nothing", so I'm dying to know what could you say that
>>>>> would be ontopic :-)
>>>> That is a risk I am not going to take.
>>> Afraid of being too plethoric?
>>
>> No afraid of killing Juanma.  He said that the knowledge could prove
>> fatal.
>
> This proves how wrong people are when they say communication here is
> hard and without empathy!

Hopefully I don't need to check my system for viruses after this
conversation!

-- 
Bastien

Re: vc-directory breakage

[Juanma Barranquero]

On Mon, May 5, 2008 at 6:40 PM, David Kastrup <dak@gnu.org> wrote:

>  He said that the knowledge could prove fatal.

Quite correct. Thanks.

 Juanma

-- 
The guitarists were doing things that would make Baron Frankenstein
say, "There are some things man was not meant to know."
                                         -- John Shirley, _ECLIPSE_

Re: vc-directory breakage

[Thomas Lord]

>>>>  There is not much I could say about gastroenteritis that would be
>>>>  ontopic in emacs-devel.


I hesitated thrice before replying to this threatening-to-be-distracting 
"joke"
thread and still found myself feeling it couldn't hurt:

In a pandemic, we could well find many programmers decommissioned
and, concurrently, a need to improvise novel, powerful, user-facing
computer applications to help society hold things together.

In such circumstance, Emacs has much to offer.   It is modest in
its requirements of the software stack below it.   It has an implementation
that, at core, one or a very few programmers can maintain and extend.
It affords its users a programming environment with a rich improvisational
capacity, even if the resulting applications are "crude" by today's most 
popular
UI / look-and-feel expectations.

It is very valuable and rare that way so one thing to keep in mind as 
I.D.E. support
is added is to K.I.S.S.

-t

Re: vc-directory breakage

[Stephen J. Turnbull]

Thomas Lord writes:

 > It is very valuable and rare that way so one thing to keep in mind
 > as I.D.E. support is added is to K.I.S.S.

A classical reference?  At least in March!

Re: vc-directory breakage

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> > I apologize for the broken state of vc-directory.  I would not
> > voluntarily have left it in a bad state, but I had an acute attack of
> > viral gastroentritis yesterday.  Unsurprisingly, a hospital emergency
> > room turns out not to be a good place from which to fix Lisp bugs.
> 
> Actually, that is an argument for a distributed version control system.
> Even while one might need to group the work into non-working checkins
> for oneself at first, one can reorganize before pushing everything out
> to the public repository.

Agreed.  :-)

To my knowledge, VC is not in a broken state now.  Stefan fixed one of
the blocker bugs yesterday, probably while I was flat on my back and
hooked up to a heart monitor, and I got the other one this morning.

I am mostly recovered, though I am still in some pain through having
strained some back muscles during the more violent nausea episodes.  Trust
me when I say you do not want this crap to happen to you...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-directory breakage

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > To my knowledge, VC is not in a broken state now.  Stefan fixed one of
  > the blocker bugs yesterday, probably while I was flat on my back and
  > hooked up to a heart monitor, and I got the other one this morning.

There still are some issues. This:

(defun vc-generic-status-printer (fileentry)
  (let* ((file (vc-dir-fileinfo->name fileentry))
         (backend (vc-responsible-backend file)))
    (vc-call-backend backend 'status-printer fileentry)))

is not quite right. 
(vc-dir-fileinfo->name fileentry) is not an absolute file name, doing
vc-responsible-backend on that is not going to work.

Also please put the backend in a buffer-local variable in the vc-dir
buffer, that way all the vc-responsible-backend calls in vc-generic-* can be
eliminated.  
With that change this code will work.
It does not work right now for at least hg, git and svn.

Re: vc-directory breakage

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
>   > To my knowledge, VC is not in a broken state now.  Stefan fixed one of
>   > the blocker bugs yesterday, probably while I was flat on my back and
>   > hooked up to a heart monitor, and I got the other one this morning.
> 
> There still are some issues. This:
> 
> (defun vc-generic-status-printer (fileentry)
>   (let* ((file (vc-dir-fileinfo->name fileentry))
>          (backend (vc-responsible-backend file)))
>     (vc-call-backend backend 'status-printer fileentry)))
> 
> is not quite right. 
> (vc-dir-fileinfo->name fileentry) is not an absolute file name, doing
> vc-responsible-backend on that is not going to work.

Ah.  There's some Lisp function I need to wrap that arg in to make
it a full pathname, then; I've forgotten which it is, though.  If you
remember before I do, feel free to fix it.

> Also please put the backend in a buffer-local variable in the vc-dir
> buffer, that way all the vc-responsible-backend calls in vc-generic-* can be
> eliminated.  
> With that change this code will work.
> It does not work right now for at least hg, git and svn.

The recommended change may be a good idea, but I'm not sure.  Those backend
checks are now being done at file granularity because some people were vocal
about support for mixing multiple VCSes in a directory.    If we depended 
on a per-directory buffer-local variable, that would get more difficult.

What is the actual failure you are seeing?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-directory breakage

[Stefan Monnier]

>> Also please put the backend in a buffer-local variable in the vc-dir
>> buffer, that way all the vc-responsible-backend calls in vc-generic-* can be
>> eliminated.  
>> With that change this code will work.
>> It does not work right now for at least hg, git and svn.

> The recommended change may be a good idea, but I'm not sure.  Those backend
> checks are now being done at file granularity because some people were vocal
> about support for mixing multiple VCSes in a directory.

I believe you have misunderstood the request, then: "support the multi-VCS
case" means exactly what Dan asks, which is "make sure only one backend
is used for a given command, even if the command includes files that are
under various backends".

I.e. the issue is not "several subdirs of *vc-dir* which each use
a different backend", but "all the files under *vc-dir* are under the
control of several backends at the same time".


        Stefan

Re: vc-directory breakage

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> I believe you have misunderstood the request, then: "support the multi-VCS
> case" means exactly what Dan asks, which is "make sure only one backend
> is used for a given command, even if the command includes files that are
> under various backends".
> 
> I.e. the issue is not "several subdirs of *vc-dir* which each use
> a different backend", but "all the files under *vc-dir* are under the
> control of several backends at the same time".

I understood the second part.  But your first paragraph leaves me
more confused than I was before.

It is already the case that "only one backend is used for a given
command, even if the command includes files that are under various
backends".  If a fileset is not all owned by the same backend, a
consistency check in vc-deduce-fileset will fail.  And C-u C-x v v 
allows us to change the preferred backend for a set of files.

What I don't see is what any of this has to do with keeping a buffer-local
backend variable per directory, which is what Dan is saying he wants.  By
hypothesis, backend is a per-*file* property.  I don't see how trying to 
cache it per directory can be a good idea.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-directory breakage

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca>:
>> I believe you have misunderstood the request, then: "support the multi-VCS
>> case" means exactly what Dan asks, which is "make sure only one backend
>> is used for a given command, even if the command includes files that are
>> under various backends".
>> 
>> I.e. the issue is not "several subdirs of *vc-dir* which each use
>> a different backend", but "all the files under *vc-dir* are under the
>> control of several backends at the same time".
>
> I understood the second part.  But your first paragraph leaves me
> more confused than I was before.
>
> It is already the case that "only one backend is used for a given
> command, even if the command includes files that are under various
> backends".  If a fileset is not all owned by the same backend, a
> consistency check in vc-deduce-fileset will fail.  And C-u C-x v v 
> allows us to change the preferred backend for a set of files.
>
> What I don't see is what any of this has to do with keeping a
> buffer-local backend variable per directory, which is what Dan is
> saying he wants.  By hypothesis, backend is a per-*file* property.

I don't think I agree.  I think that a single buffer should be
associated with a single version control system, period.  This also
holds for VC directories.  They have files which are under _their_
version control, and files that aren't.  No more distinctions than that.
When visiting a file buffer via that VC directory, its backend should be
changed to match the backend of the VC.  When visiting a VC directory
from a file buffer in a certain backend, either a separate buffer should
be created (possibly containing the VC name in its name), or the
existing buffer should be scrapped and reentered.  In order to not lose
any marks and stuff, it might be nicest if the version control system
was made part of the buffer name, and visiting the directory under
different VC systems managed different buffers.

> I don't see how trying to cache it per directory can be a good idea.

Not per directory.  Per buffer, and that includes VC directory buffers.
When using C-x v d, the current version control backend of the current
buffer should get used.  If there is none, it may get deduced
automatically in some manner.

-- 
David Kastrup

Re: vc-directory breakage

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca>:
  > > I believe you have misunderstood the request, then: "support the multi-VCS
  > > case" means exactly what Dan asks, which is "make sure only one backend
  > > is used for a given command, even if the command includes files that are
  > > under various backends".
  > > 
  > > I.e. the issue is not "several subdirs of *vc-dir* which each use
  > > a different backend", but "all the files under *vc-dir* are under the
  > > control of several backends at the same time".
  > 
  > I understood the second part.  But your first paragraph leaves me
  > more confused than I was before.
  > 
  > It is already the case that "only one backend is used for a given
  > command, even if the command includes files that are under various
  > backends".  If a fileset is not all owned by the same backend, a
  > consistency check in vc-deduce-fileset will fail.  And C-u C-x v v 
  > allows us to change the preferred backend for a set of files.
  > 
  > What I don't see is what any of this has to do with keeping a buffer-local
  > backend variable per directory, which is what Dan is saying he wants.  By
  > hypothesis, backend is a per-*file* property.  I don't see how trying to 
  > cache it per directory can be a good idea.

It is not per-directory, it is per vc-dir view.  vc-dir was designed to
show the VC state of a subdirectory through a specific backend.  There
are UI features that take advantage from doing that: the headers can
show backend specific information, things like branches, the module name
for CVS, the repository, etc.  Also backends provide backend specific
menus (git and hg already do that).
This will be a complete mess if headers/menus from multiple backends
would appear.
It is still possible to use different backends for the same
directory: just add a prefix arg to vc-dir that asks about what backend
to use.

Re: vc-directory breakage

[Stefan Monnier]

>> I believe you have misunderstood the request, then: "support the multi-VCS
>> case" means exactly what Dan asks, which is "make sure only one backend
>> is used for a given command, even if the command includes files that are
>> under various backends".
>> 
>> I.e. the issue is not "several subdirs of *vc-dir* which each use
>> a different backend", but "all the files under *vc-dir* are under the
>> control of several backends at the same time".

> I understood the second part.  But your first paragraph leaves me
> more confused than I was before.

> It is already the case that "only one backend is used for a given
> command, even if the command includes files that are under various
> backends".  If a fileset is not all owned by the same backend, a
> consistency check in vc-deduce-fileset will fail.

Why should it fail?

> What I don't see is what any of this has to do with keeping a buffer-local
> backend variable per directory, which is what Dan is saying he wants.

It's not per-directory.  It's per-buffer.  This way, there is no need to
check consistency within vc-deduce-fileset: it's consistent by construction.

> By hypothesis, backend is a per-*file* property.

Let's say I have a tree in ~/foo that's under both CVS and Arch.
Let's say I open a vc-dir on ~/foo where I want to see the Arch state.
Now let's say I also open the file ~/foo/toto.c and choose the CVS
backend in that buffer.

With the per-file backend you have the problem that ~/foo/titi.c is
(presumably) using Arch whereas ~/foo/toto.c is using CVS, so your
`diff' operation in the ~/foo vc-dir will fail complaining of an
inconsistent fileset.

With the per-buffer backend, there is no such problem.


        Stefan

Re: vc-directory breakage

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > "Eric S. Raymond" <esr@thyrsus.com> writes:
  > > 
  > >   > To my knowledge, VC is not in a broken state now.  Stefan fixed one of
  > >   > the blocker bugs yesterday, probably while I was flat on my back and
  > >   > hooked up to a heart monitor, and I got the other one this morning.
  > > 
  > > There still are some issues. This:
  > > 
  > > (defun vc-generic-status-printer (fileentry)
  > >   (let* ((file (vc-dir-fileinfo->name fileentry))
  > >          (backend (vc-responsible-backend file)))
  > >     (vc-call-backend backend 'status-printer fileentry)))
  > > 
  > > is not quite right. 
  > > (vc-dir-fileinfo->name fileentry) is not an absolute file name, doing
  > > vc-responsible-backend on that is not going to work.
  > 
  > Ah.  There's some Lisp function I need to wrap that arg in to make
  > it a full pathname, then; I've forgotten which it is, though

expand-file-name

  > > Also please put the backend in a buffer-local variable in the vc-dir
  > > buffer, that way all the vc-responsible-backend calls in vc-generic-* can be
  > > eliminated.  
  > > With that change this code will work.
  > > It does not work right now for at least hg, git and svn.
  > 
  > The recommended change may be a good idea, but I'm not sure.  Those backend
  > checks are now being done at file granularity because some people were vocal
  > about support for mixing multiple VCSes in a directory.    If we depended 
  > on a per-directory buffer-local variable, that would get more difficult.

Stefan just explained this one.

  > What is the actual failure you are seeing?

For a mercurial repo:

  intern(nil [0 0 0 0 Makefile\.mk 0 0 0 0 0 0 0 0 0 ~/r/hgtest/ 0 0])
  vc-file-getprop(nil vc-mtn-root)
  vc-mtn-root("Makefile.mk")
  vc-mtn-responsible-p("Makefile.mk")
  apply(vc-mtn-responsible-p "Makefile.mk")
  vc-call-backend(Mtn responsible-p "Makefile.mk")
  byte-code("^H\306^Y\211^Z\203+^@\n@^Q^K\203^W^@\307   \310\f#\204$^@\307      \311\f#\203$^@\312\313  \"\210\nA\211^R\204^H^@*^$
  vc-responsible-backend("Makefile.mk")
  vc-generic-status-printer(("Makefile.mk" added [cl-struct-vc-hg-extra-fileinfo copied "Makefile"] nil nil nil))
  #[(G76001 data) "^HJ  !\210\302c\207" [G76001 data "\n"] 2](--ewoc--user-pp-- ("Makefile.mk" added [cl-struct-vc-hg-extra-filei$
  apply(#[(G76001 data) "^HJ    !\210\302c\207" [G76001 data "\n"] 2] --ewoc--user-pp-- ("Makefile.mk" added [cl-struct-vc-hg-ext$
  (lambda (&rest --cl-rest--) (apply #[... "^HJ !\210\302c\207" [G76001 data "\n"] 2] (quote --ewoc--user-pp--) --cl-rest--))(("M$
  ewoc--refresh-node((lambda (&rest --cl-rest--) (apply #[... "^HJ      !\210\302c\207" [G76001 data "\n"] 2] (quote --ewoc--user$
  ewoc-invalidate([cl-struct-ewoc #<buffer *vc-dir*> (lambda (&rest --cl-rest--) (apply #[... "^HJ      !\210\302c\207" [G76001 d$
  vc-dir-update((("config.h" missing nil) ("config.mk" edited nil) ("dmenu_path" removed nil) ("b/c" edited nil) ("m/n" edited ni$
  #[(G37817 entries &optional more-to-come) "r^HJq\210\306      ^HJ\"\210\n?\205'^@\307^K\310\"\211^\\203#^@\311\312\313\f\"\314\$
  apply(#[(G37817 entries &optional more-to-come) "r^HJq\210\306        ^HJ\"\210\n?\205'^@\307^K\310\"\211^\\203#^@\311\312\313\$
  (lambda (&rest --cl-rest--) (apply #[... "r^HJq\210\306       ^HJ\"\210\n?\205'^@\307^K\310\"\211^\\203#^@\311\312\313\f\"\314\$
  vc-hg-after-dir-status((lambda (&rest --cl-rest--) (apply #[... "r^HJq\210\306        ^HJ\"\210\n?\205'^@\307^K\310\"\211^\\203$
  eval((vc-hg-after-dir-status (quote (lambda ... ...))))
  vc-exec-after((vc-hg-after-dir-status (quote (lambda ... ...))))
  vc-process-sentinel(#<process hg> "finished\n")

Re: vc-directory breakage

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
>   > The recommended change may be a good idea, but I'm not sure.
>   > Those backend checks are now being done at file granularity
>   > because some people were vocal about support for mixing multiple
>   > VCSes in a directory.  If we depended on a per-directory
>   > buffer-local variable, that would get more difficult.  
>
> Stefan just explained this one.

Yes, but his explanation left me more confused than before :-)  I
still don't get why per-directory caching helps anything.

>   > What is the actual failure you are seeing?
> 
> For a mercurial repo:
> 
>   intern(nil [0 0 0 0 Makefile\.mk 0 0 0 0 0 0 0 0 0 ~/r/hgtest/ 0 0])
>   vc-file-getprop(nil vc-mtn-root)
>   vc-mtn-root("Makefile.mk")
>   vc-mtn-responsible-p("Makefile.mk")
>   apply(vc-mtn-responsible-p "Makefile.mk")
>   vc-call-backend(Mtn responsible-p "Makefile.mk")

This looks to me like a failure in the root backend method, not a generic
problem in the VC front end.  What am I missing here?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-directory breakage

[Dan Nicolaescu]

"Eric S. Raymond" <esr@thyrsus.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > >   > What is the actual failure you are seeing?
  > > 
  > > For a mercurial repo:
  > > 
  > >   intern(nil [0 0 0 0 Makefile\.mk 0 0 0 0 0 0 0 0 0 ~/r/hgtest/ 0 0])
  > >   vc-file-getprop(nil vc-mtn-root)
  > >   vc-mtn-root("Makefile.mk")
  > >   vc-mtn-responsible-p("Makefile.mk")
  > >   apply(vc-mtn-responsible-p "Makefile.mk")
  > >   vc-call-backend(Mtn responsible-p "Makefile.mk")
  > 
  > This looks to me like a failure in the root backend method, not a generic
  > problem in the VC front end.  What am I missing here?

A few lines below what you cited:

  vc-responsible-backend("Makefile.mk")
                         ^^^^^^^^^^^^
either having the backend available, or using an absolute file name
would make this work.

Re: vc-directory breakage

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu>:
>   > >   > What is the actual failure you are seeing?
>   > > 
>   > > For a mercurial repo:
>   > > 
>   > >   intern(nil [0 0 0 0 Makefile\.mk 0 0 0 0 0 0 0 0 0 ~/r/hgtest/ 0 0])
>   > >   vc-file-getprop(nil vc-mtn-root)
>   > >   vc-mtn-root("Makefile.mk")
>   > >   vc-mtn-responsible-p("Makefile.mk")
>   > >   apply(vc-mtn-responsible-p "Makefile.mk")
>   > >   vc-call-backend(Mtn responsible-p "Makefile.mk")
>   > 
>   > This looks to me like a failure in the root backend method, not a generic
>   > problem in the VC front end.  What am I missing here?
> 
> A few lines below what you cited:
> 
>   vc-responsible-backend("Makefile.mk")
>                          ^^^^^^^^^^^^
> either having the backend available, or using an absolute file name
> would make this work.

OK, then I think I've fixed this one already.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-directory breakage

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> The recommended change may be a good idea, but I'm not sure.  Those
> backend checks are now being done at file granularity because some
> people were vocal about support for mixing multiple VCSes in a
> directory.  If we depended on a per-directory buffer-local variable,
> that would get more difficult.

Not at all.  The buffer-local variable is just used for starting off the
directory in the right mode and keeping it there.

The question one needs to solve is what to do when a command would reuse
*vc-dir* and would have an idea gained from the buffer where the command
has been issued just what backend *vc-dir* should be using, and *vc-dir*
is actually different.

There are two solutions I see for that: it could scrap the existing
buffer completely, or it could get-buffer-create *vc-dir*<backend> (with
the proper backend spelled out in the brackets).  If the normal mode of
operation would scrap the buffer too without leaving existing
information in it, that would be the obvious choice.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum