* vc-directory breakage @ 2008-05-05 15:21 Eric S. Raymond 2008-05-05 15:32 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Eric S. Raymond @ 2008-05-05 15:21 UTC (permalink / raw To: emacs-devel 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! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:21 vc-directory breakage Eric S. Raymond @ 2008-05-05 15:32 ` David Kastrup 2008-05-05 15:39 ` Bastien Guerry 2008-05-06 0:04 ` Eric S. Raymond 0 siblings, 2 replies; 26+ messages in thread From: David Kastrup @ 2008-05-05 15:32 UTC (permalink / raw To: Eric S. Raymond; +Cc: emacs-devel "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:32 ` David Kastrup @ 2008-05-05 15:39 ` Bastien Guerry 2008-05-05 15:45 ` David Kastrup 2008-05-06 0:04 ` Eric S. Raymond 1 sibling, 1 reply; 26+ messages in thread From: Bastien Guerry @ 2008-05-05 15:39 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:39 ` Bastien Guerry @ 2008-05-05 15:45 ` David Kastrup 2008-05-05 15:52 ` Juanma Barranquero 0 siblings, 1 reply; 26+ messages in thread From: David Kastrup @ 2008-05-05 15:45 UTC (permalink / raw To: Bastien Guerry; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:45 ` David Kastrup @ 2008-05-05 15:52 ` Juanma Barranquero 2008-05-05 16:03 ` David Kastrup 0 siblings, 1 reply; 26+ messages in thread From: Juanma Barranquero @ 2008-05-05 15:52 UTC (permalink / raw To: David Kastrup; +Cc: Bastien Guerry, emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:52 ` Juanma Barranquero @ 2008-05-05 16:03 ` David Kastrup 2008-05-05 16:23 ` Bastien Guerry 0 siblings, 1 reply; 26+ messages in thread From: David Kastrup @ 2008-05-05 16:03 UTC (permalink / raw To: Juanma Barranquero; +Cc: Bastien Guerry, emacs-devel "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:03 ` David Kastrup @ 2008-05-05 16:23 ` Bastien Guerry 2008-05-05 16:40 ` David Kastrup 2008-05-05 22:09 ` Thomas Lord 0 siblings, 2 replies; 26+ messages in thread From: Bastien Guerry @ 2008-05-05 16:23 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:23 ` Bastien Guerry @ 2008-05-05 16:40 ` David Kastrup 2008-05-05 16:50 ` Lennart Borgman (gmail) 2008-05-05 20:14 ` Juanma Barranquero 2008-05-05 22:09 ` Thomas Lord 1 sibling, 2 replies; 26+ messages in thread From: David Kastrup @ 2008-05-05 16:40 UTC (permalink / raw To: Bastien Guerry; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:40 ` David Kastrup @ 2008-05-05 16:50 ` Lennart Borgman (gmail) 2008-05-05 17:00 ` Bastien Guerry 2008-05-05 20:14 ` Juanma Barranquero 1 sibling, 1 reply; 26+ messages in thread From: Lennart Borgman (gmail) @ 2008-05-05 16:50 UTC (permalink / raw To: David Kastrup; +Cc: Bastien Guerry, emacs-devel 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! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:50 ` Lennart Borgman (gmail) @ 2008-05-05 17:00 ` Bastien Guerry 0 siblings, 0 replies; 26+ messages in thread From: Bastien Guerry @ 2008-05-05 17:00 UTC (permalink / raw To: emacs-devel "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:40 ` David Kastrup 2008-05-05 16:50 ` Lennart Borgman (gmail) @ 2008-05-05 20:14 ` Juanma Barranquero 1 sibling, 0 replies; 26+ messages in thread From: Juanma Barranquero @ 2008-05-05 20:14 UTC (permalink / raw To: David Kastrup; +Cc: Bastien Guerry, emacs-devel 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_ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 16:23 ` Bastien Guerry 2008-05-05 16:40 ` David Kastrup @ 2008-05-05 22:09 ` Thomas Lord 2008-05-05 22:17 ` Stephen J. Turnbull 1 sibling, 1 reply; 26+ messages in thread From: Thomas Lord @ 2008-05-05 22:09 UTC (permalink / raw To: Bastien Guerry; +Cc: emacs-devel >>>> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 22:09 ` Thomas Lord @ 2008-05-05 22:17 ` Stephen J. Turnbull 0 siblings, 0 replies; 26+ messages in thread From: Stephen J. Turnbull @ 2008-05-05 22:17 UTC (permalink / raw To: Thomas Lord; +Cc: Bastien Guerry, emacs-devel 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! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-05 15:32 ` David Kastrup 2008-05-05 15:39 ` Bastien Guerry @ 2008-05-06 0:04 ` Eric S. Raymond 2008-05-06 0:36 ` Dan Nicolaescu 1 sibling, 1 reply; 26+ messages in thread From: Eric S. Raymond @ 2008-05-06 0:04 UTC (permalink / raw To: David Kastrup; +Cc: Eric S. Raymond, emacs-devel 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 0:04 ` Eric S. Raymond @ 2008-05-06 0:36 ` Dan Nicolaescu 2008-05-06 0:48 ` Eric S. Raymond 0 siblings, 1 reply; 26+ messages in thread From: Dan Nicolaescu @ 2008-05-06 0:36 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, emacs-devel "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 0:36 ` Dan Nicolaescu @ 2008-05-06 0:48 ` Eric S. Raymond 2008-05-06 1:03 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Eric S. Raymond @ 2008-05-06 0:48 UTC (permalink / raw To: Dan Nicolaescu; +Cc: Eric S. Raymond, emacs-devel 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 0:48 ` Eric S. Raymond @ 2008-05-06 1:03 ` Stefan Monnier 2008-05-06 8:21 ` Eric S. Raymond 2008-05-06 1:10 ` Dan Nicolaescu 2008-05-06 6:36 ` David Kastrup 2 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2008-05-06 1:03 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, Dan Nicolaescu, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 1:03 ` Stefan Monnier @ 2008-05-06 8:21 ` Eric S. Raymond 2008-05-06 9:08 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Eric S. Raymond @ 2008-05-06 8:21 UTC (permalink / raw To: Stefan Monnier; +Cc: Eric S. Raymond, Dan Nicolaescu, emacs-devel 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 8:21 ` Eric S. Raymond @ 2008-05-06 9:08 ` David Kastrup 2008-05-06 16:34 ` Dan Nicolaescu 2008-05-07 1:30 ` Stefan Monnier 2 siblings, 0 replies; 26+ messages in thread From: David Kastrup @ 2008-05-06 9:08 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, Dan Nicolaescu, Stefan Monnier, emacs-devel "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 8:21 ` Eric S. Raymond 2008-05-06 9:08 ` David Kastrup @ 2008-05-06 16:34 ` Dan Nicolaescu 2008-05-07 1:30 ` Stefan Monnier 2 siblings, 0 replies; 26+ messages in thread From: Dan Nicolaescu @ 2008-05-06 16:34 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, Stefan Monnier, emacs-devel "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 8:21 ` Eric S. Raymond 2008-05-06 9:08 ` David Kastrup 2008-05-06 16:34 ` Dan Nicolaescu @ 2008-05-07 1:30 ` Stefan Monnier 2 siblings, 0 replies; 26+ messages in thread From: Stefan Monnier @ 2008-05-07 1:30 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, Dan Nicolaescu, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 0:48 ` Eric S. Raymond 2008-05-06 1:03 ` Stefan Monnier @ 2008-05-06 1:10 ` Dan Nicolaescu 2008-05-06 9:01 ` Eric S. Raymond 2008-05-06 6:36 ` David Kastrup 2 siblings, 1 reply; 26+ messages in thread From: Dan Nicolaescu @ 2008-05-06 1:10 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, emacs-devel "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") ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 1:10 ` Dan Nicolaescu @ 2008-05-06 9:01 ` Eric S. Raymond 2008-05-06 12:03 ` Dan Nicolaescu 0 siblings, 1 reply; 26+ messages in thread From: Eric S. Raymond @ 2008-05-06 9:01 UTC (permalink / raw To: Dan Nicolaescu; +Cc: Eric S. Raymond, emacs-devel 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 9:01 ` Eric S. Raymond @ 2008-05-06 12:03 ` Dan Nicolaescu 2008-05-06 16:03 ` Eric S. Raymond 0 siblings, 1 reply; 26+ messages in thread From: Dan Nicolaescu @ 2008-05-06 12:03 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, emacs-devel "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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 12:03 ` Dan Nicolaescu @ 2008-05-06 16:03 ` Eric S. Raymond 0 siblings, 0 replies; 26+ messages in thread From: Eric S. Raymond @ 2008-05-06 16:03 UTC (permalink / raw To: Dan Nicolaescu; +Cc: Eric S. Raymond, emacs-devel 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> ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: vc-directory breakage 2008-05-06 0:48 ` Eric S. Raymond 2008-05-06 1:03 ` Stefan Monnier 2008-05-06 1:10 ` Dan Nicolaescu @ 2008-05-06 6:36 ` David Kastrup 2 siblings, 0 replies; 26+ messages in thread From: David Kastrup @ 2008-05-06 6:36 UTC (permalink / raw To: esr; +Cc: Eric S. Raymond, Dan Nicolaescu, emacs-devel "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 ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2008-05-07 1:30 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-05-05 15:21 vc-directory breakage Eric S. Raymond 2008-05-05 15:32 ` David Kastrup 2008-05-05 15:39 ` Bastien Guerry 2008-05-05 15:45 ` David Kastrup 2008-05-05 15:52 ` Juanma Barranquero 2008-05-05 16:03 ` David Kastrup 2008-05-05 16:23 ` Bastien Guerry 2008-05-05 16:40 ` David Kastrup 2008-05-05 16:50 ` Lennart Borgman (gmail) 2008-05-05 17:00 ` Bastien Guerry 2008-05-05 20:14 ` Juanma Barranquero 2008-05-05 22:09 ` Thomas Lord 2008-05-05 22:17 ` Stephen J. Turnbull 2008-05-06 0:04 ` Eric S. Raymond 2008-05-06 0:36 ` Dan Nicolaescu 2008-05-06 0:48 ` Eric S. Raymond 2008-05-06 1:03 ` Stefan Monnier 2008-05-06 8:21 ` Eric S. Raymond 2008-05-06 9:08 ` David Kastrup 2008-05-06 16:34 ` Dan Nicolaescu 2008-05-07 1:30 ` Stefan Monnier 2008-05-06 1:10 ` Dan Nicolaescu 2008-05-06 9:01 ` Eric S. Raymond 2008-05-06 12:03 ` Dan Nicolaescu 2008-05-06 16:03 ` Eric S. Raymond 2008-05-06 6:36 ` David Kastrup
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).