vc-diff in non-VC buffer

vc-diff in non-VC buffer

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

AFAICS,

C:\> emacs -Q -D
C-x v =

=> launches a traversal of the hard disk.

C:\tmp> emacs -Q -D        (C:\tmp is an empty dir)
C-x v =

=>
------------------------------------------------------------
Diffs between focus version and workfile:

cvs rcsfile: connect to 127.0.0.1(127.0.0.1):2402 failed: No se ha
podido establecer conexión ya que el equipo de destino ha denegado
activamente dicha conexión.
cvs [rcsfile aborted]: Couldn't connect to lock server


Diffs between focus version and workfile end here.
------------------------------------------------------------

Hmm. Not Good.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> Hmm. Not Good.

A recursive check for version differences is not what you expected? 
It seems the most natural thing to do there.  If you don't want the
entire file tree under your home directory scanned, don't do that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Juanma Barranquero]

On 10/10/07, Eric S. Raymond <esr@thyrsus.com> wrote:

> A recursive check for version differences is not what you expected?
> It seems the most natural thing to do there.

When I'm visiting a file that is not under any version control system,
then no, I don't expect a recursive check. I expect an error message.

Is not uncommon for me to do C-x v = accidentally while visiting files
that are not under version control, because I have the same files in
several environments, but I only use version control in one of them.

             Juanma

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> On 10/10/07, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > A recursive check for version differences is not what you expected?
> > It seems the most natural thing to do there.
> 
> When I'm visiting a file that is not under any version control system,
> then no, I don't expect a recursive check. I expect an error message.

Hm.  Even if there are other version-controlled files beneath the 
current directory?

I can change this behavior.  But I was preserving an earlier capability 
to say, in effect, "tell me what has changed under this directory,
*without* making me list all the files to diff".

I think people are likely to become quite upset with me if I
remove that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Juanma Barranquero]

On 10/10/07, Eric S. Raymond <esr@thyrsus.com> wrote:

> Hm.  Even if there are other version-controlled files beneath the
> current directory?

Well, I'm not sure about this case, I'd have to think it over. I
suppose that such behavior would make sense when asking for vc-diff in
dired, or selecting a directory in some way. But vc-diff in a buffer
visiting a file *not* under version-control... no, I wouldn't expect a
tree search.

Anyway, I have no version-controlled files in my %HOME dir or beneath
it, and C-x v = while editing the .emacs file now tries to do some
version-control processing (with predictably bad results), while
before it just said: "File c:/home/.emacs is not under version
control", which seems sensible.

I'm not saying my view is the only one reasonable, but to me the
current behavior is a regression.

> I think people are likely to become quite upset with me if I
> remove that.

Then at the very least make it a user option, please.

             Juanma

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> I'm not saying my view is the only one reasonable, but to me the
> current behavior is a regression.

I hear that.  Let's try to think about smarter ways for the code to behave.
 
> > I think people are likely to become quite upset with me if I
> > remove that.
> 
> Then at the very least make it a user option, please.

I'd rather not.  Doing the right thing is better than options, when
you can figure out what it is.  And too often, adding options becomes
an excuse not to figure that out.

How about this: VC can test whether some VCS considers itself responsible
for a directory.  I could change the logic to error out when no VCS considers
itself responsible for the current directory. Would that cover your
use case?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Juanma Barranquero]

On 10/11/07, Eric S. Raymond <esr@thyrsus.com> wrote:
> Juanma Barranquero <lekktu@gmail.com>:

> How about this: VC can test whether some VCS considers itself responsible
> for a directory.  I could change the logic to error out when no VCS considers
> itself responsible for the current directory. Would that cover your
> use case?

I think so, yes.

             Juanma

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> > How about this: VC can test whether some VCS considers itself responsible
> > for a directory.  I could change the logic to error out when no VCS considers
> > itself responsible for the current directory. Would that cover your
> > use case?
> 
> I think so, yes.

It's on my to-do list.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Juanma Barranquero]

On 10/11/07, Eric S. Raymond <esr@thyrsus.com> wrote:

> It's on my to-do list.

Thanks.

             Juanma

Re: vc-diff in non-VC buffer

[Richard Stallman]

    How about this: VC can test whether some VCS considers itself responsible
    for a directory.  I could change the logic to error out when no VCS considers
    itself responsible for the current directory. Would that cover your
    use case?

In user terms, what would the resulting behavior be?  Does it implement
Stefan's suggestion, which I believe is the right behavior?

Re: vc-diff in non-VC buffer

[Andreas Schwab]

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

> Hm.  Even if there are other version-controlled files beneath the 
> current directory?
>
> I can change this behavior.  But I was preserving an earlier capability 
> to say, in effect, "tell me what has changed under this directory,
> *without* making me list all the files to diff".

I don't see this behaviour with 22.1.  There you'll get an error.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Andreas Schwab <schwab@suse.de>:
> I don't see this behaviour with 22.1.  There you'll get an error.

It was an alternate form of the diff command.  I don't remember
the details any more.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Richard Stallman]

    C:\> emacs -Q -D
    C-x v =

    => launches a traversal of the hard disk.

I think it should verify that the current buffer corresponds to a
version-controlled directory or file.  Eric, do you see any
argument against doing so?

Re: vc-diff in non-VC buffer

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
>     C:\> emacs -Q -D
>     C-x v =
> 
>     => launches a traversal of the hard disk.
> 
> I think it should verify that the current buffer corresponds to a
> version-controlled directory or file.  Eric, do you see any
> argument against doing so?

Yes.  For that particular operation, and some other non-modifying ones
such as printing change-history logs, what users often want is a
fallback rule for computing selected filesets that says, in effect:
if the selected fileset is empty, look at all version-controlled 
files beneath the current directory.  

So, for example, you can go to a top-level project directory and just
do C-x v = to look at the state of all changes beneath it, regardless
of whether you're actually visiting a controlled file.  This is useful,
and I think many VC users would be (rightly) annoyed if they lost it.

What Juanma is pointing out is that this rule grinds your disk in what
is for him an unhelpful way when you do C-x v = from $HOME.  He's got a
point; aggregating diffs from the multiple projects that doubtless live
under there is not likely to be useful. 

I'm testing code that errors out if you (a) have an empty fileset, and
(b) no files are registered immediately under default-directory.  Juanma
thinks this will cover his use case.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: vc-diff in non-VC buffer

[Stefan Monnier]

> So, for example, you can go to a top-level project directory and just
> do C-x v = to look at the state of all changes beneath it, regardless
> of whether you're actually visiting a controlled file.  This is useful,
> and I think many VC users would be (rightly) annoyed if they lost it.

I don't know of such a feature, so I doubt many users would "miss it".

The above scenario to me has the following problem: when you say "go to
a top-level project directory", this can mean to do it by opening some
arbitrary file in that top-level dir or by opening the dir with dired or
with vc-dired.

Of those 3 cases, I think the first case should not be supported.  C-v x =
from a file buffer should only apply to that file.  The third should of
course be supported and the one I expect people to use.

The second doesn't matter: if it works, it's harmless and if it doesn't it's
not serious either because the user could have used vc-dired instead.
But it should only work if the corresponding dir is under some kind of
version control, of course.

> I'm testing code that errors out if you (a) have an empty fileset, and
> (b) no files are registered immediately under default-directory.  Juanma
> thinks this will cover his use case.

Don't check files: it should work in a BACKEND-controlled directory even if no
files are currently registered in BACKEND yet.  Check `responsible-p' or
something like that (applied to the directory) instead.


        Stefan

Re: vc-diff in non-VC buffer

[Richard Stallman]

    The above scenario to me has the following problem: when you say "go to
    a top-level project directory", this can mean to do it by opening some
    arbitrary file in that top-level dir or by opening the dir with dired or
    with vc-dired.

    Of those 3 cases, I think the first case should not be supported.  C-v x =
    from a file buffer should only apply to that file.  The third should of
    course be supported and the one I expect people to use.

    The second doesn't matter: if it works, it's harmless and if it doesn't it's
    not serious either because the user could have used vc-dired instead.
    But it should only work if the corresponding dir is under some kind of
    version control, of course.

I agree completely.

Re: vc-diff in non-VC buffer

[Richard Stallman]

    Yes.  For that particular operation, and some other non-modifying ones
    such as printing change-history logs, what users often want is a
    fallback rule for computing selected filesets that says, in effect:
    if the selected fileset is empty, look at all version-controlled 
    files beneath the current directory.  

Is that really the right condition?  I think it is not quite right.
I do not want it to search your tree when that is not wanted.

    I'm testing code that errors out if you (a) have an empty fileset, and
    (b) no files are registered immediately under default-directory.  Juanma
    thinks this will cover his use case.

What will this do in the original case:
you visit a file in your home dir and tyoe C-x v =.
In that case, do you have a nonempty fileset?
If so, it sounds like the criterion for the error
would not be met, and it would search your whole tree.