unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: esr@thyrsus.com
Cc: "Eric S. Raymond" <esr@snark.thyrsus.com>,
	Dan Nicolaescu <dann@ics.uci.edu>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel@gnu.org
Subject: Re: vc-directory breakage
Date: Tue, 06 May 2008 11:08:53 +0200	[thread overview]
Message-ID: <86ej8fztne.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <20080506082112.GC23773@thyrsus.com> (Eric S. Raymond's message of "Tue, 6 May 2008 04:21:12 -0400")

"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




  reply	other threads:[~2008-05-06  9:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ej8fztne.fsf@lola.quinscape.zz \
    --to=dak@gnu.org \
    --cc=dann@ics.uci.edu \
    --cc=emacs-devel@gnu.org \
    --cc=esr@snark.thyrsus.com \
    --cc=esr@thyrsus.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).