Redesigh of the VC front end

Redesigh of the VC front end

[Eric S. Raymond]

This is a design proposal which I'm posting for comment and critique.

Some months ago I rewrote the vc.el backends because the the API to
them needed a rethink in order to handle multi-file changeset commmits.
More recently, it has become evident that the front end's interface design
needs a rethink as well.  While it works with multi-file changeset commits,
there has been no clean way to specify an operation on a directory or an 
entire repo.  Instead, vc-deduce-fileset has had a tricky set of rules that
expanded directories into directory file lists in certain special cases.

Presently the rules work like this:

1. If we're in a VC-dired or VC-dir buffer and a nonempty fileset
has been marked, return that fileset.

2. Otherwise, if you are in a vc dired buffer, and
include-files-not-directories is non-nil, and no fileset is selected,
select all files at and below directory level.

3. Otherwise, if we're in a buffer visiting a version-controlled file, the
selection set is a singleton containing that file.

4. Otherwise, if we're visiting a change-comment or log buffer, the
fileset is the one associated with its parent buffer

5. Otherwise, if allow-directory-wildcard is on-nil, and you're in a 
dired directory, select all files below the current directory

6. Otherwise, if we're allowing selection of unregistered files and
the current buffer is visiting one, return that singleton set.

Stefan Monnier thinks rule 5 is a misfeature and he's got a point.
Rule 2 is a misfeature for similar reasons; they're both ways to get
around the fact that directories aren't really first-class in Dired
and cannot be passed back to a Dired client (the client gets all of
their files as part of the merked set, instead).

More generally, these rules are messy and complicated.  They have a
functional gap as well; there is no way at all to designate a selection that
says "I don't care where we are, operate on the entire repo", which is 
an important concept when doing (say) commits or log-print requests on
any VCS from Subversion onwards.

Neither of these problems (selecting directories or selecting the
whole repo) can be solved as long as the VC interface is tied to
Dired.  Dired is just too file-oriented.  Fortunately, Dan Nicolaescu
and Stefan Monnier have written much of a dired-like browser front end
using ewoc.  The ewoc code is flexible enough to allow us to select 
directories as filesets, though it is presently being used only
as a sort of Dired emulation.

So the Dired code has to go, once the vc-dir code is at functional
parity to it.  This will take a little more work.

Here are the new rules I propose to implement:

1. If we're in a vc-dir buffer and a nonempty fileset
has been marked, return that fileset.  A fileset may include marked
directories.

2. When the backend supports the concept, every vc-dir buffer has a
special top-line entry that can be marked to select the entire repo.

3. If we're in a buffer visiting a version-controlled file, the
selection set is a singleton containing that file.

I plan to get rid of include-files-not-directories and
allow-directory-wildcard and pass directory names to the backends when
that's what the user selected.  This means that file-oriented back ends
(SCCS, RCS, CVS) will have to do directory expansion for themselves
when it is needed.

There is also a bit of murk around the handling of unregistered files.
I haven't completely thought that one out yet.  I think the code can be
rewritten so that filesets of unregistered files are simply passed to
the back end, yielding the VCS's own error for this case when the user
did not select 'register' as the operation.

Finally, anyone interested in working on or just undertstanding this code
should note that I have split vc.el in half.  The interface logic now lives
in vc-dispatcher.el, which knows all about the VC user interface and (almost)
nothing about VCSes or back ends.  This code could be used for other things,
like implementing a Midnight-Commander-style file manager.  (By the time
I'm done, I expect to be able to remove that "(almost)".)

One goal in doing this was to reduce the global complexity of
vc.el. That has been achieved; the interface between them is very
narrow and well-defined, consisting only about 6 functions.  Just as
importantly, I did this in order to separate in my own mind the UI
issues from the VCS logic.

Barring more weirdness like the gastritis thing that put me in the 
hospital yesterday, I expect to get all this done within the next two weeks.
I have put a temporary hold on my other projects to concentrate on it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

A man who has nothing which he is willing to fight for, nothing 
which he cares about more than he does about his personal safety, 
is a miserable creature who has no chance of being free, unless made 
and kept so by the exertions of better men than himself. 
	-- John Stuart Mill, writing on the U.S. Civil War in 1862

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > 2. Otherwise, if you are in a vc dired buffer, and
  > include-files-not-directories is non-nil, and no fileset is selected,
  > select all files at and below directory level.

This is a wart that is used by vc-next-action for the following: if in a
vc-dir buffer, you have a directory selected and do C-x v v what action 
should be performed?
If you have files selected, the decision is made based on the files state.
For directories, then with this flag, return the list of files is
returned and the decision based on the file state.  The VC action is
still performed on the directory...
Better ideas on how to handle this case are quite welcome.

Re: Redesigh of the VC front end

[Stefan Monnier]

> 2. Otherwise, if you are in a vc dired buffer, and
> include-files-not-directories is non-nil, and no fileset is selected,
> select all files at and below directory level.

This is bad.  It should simply return the "file or directory under
point".

> 2. When the backend supports the concept, every vc-dir buffer has a
> special top-line entry that can be marked to select the entire repo.

In PCL-CVS we list subdirectories, including ".", which is hence not
particularly special.  But maybe there's a difference between "." and
"the entire repo".

> So the Dired code has to go, once the vc-dir code is at functional
> parity to it.  This will take a little more work.

In many respects the vc-dir code will never be at parity with vc-dired,
unless we make a special effort to merge it again with dired.  I.e. we
shouldn't forget that some people liked to do dired operations from
vc-dired.

For what it's worth, I don't think that merging the two is necessarily
a bad idea.  But it seems terribly difficult to be able to do such
a combined mode that's both as good as dired and as good as vc-dir.

> that's what the user selected.  This means that file-oriented back ends
> (SCCS, RCS, CVS) will have to do directory expansion for themselves
> when it is needed.

Actually, CVS handles directories just fine in most respects.

> There is also a bit of murk around the handling of unregistered files.
> I haven't completely thought that one out yet.  I think the code can be
> rewritten so that filesets of unregistered files are simply passed to
> the back end, yielding the VCS's own error for this case when the user
> did not select 'register' as the operation.

100% agreement, especially because there may be good reasons for the
user to do that (e.g. if Emacs's notion of registration is buggy, or
out-of-date, or because the backend includes special semantics for them
(e.g. its "commit" operation may automatically add the unregistered
files mentioned on the command line).


        Stefan

Re: Redesigh of the VC front end

[Karl Fogel]

"Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> More generally, these rules are messy and complicated.  They have a
> functional gap as well; there is no way at all to designate a selection that
> says "I don't care where we are, operate on the entire repo", which is 
> an important concept when doing (say) commits or log-print requests on
> any VCS from Subversion onwards.

When you say "repo", do you sometimes mean what Subversion would call
the "working copy" and sometimes mean what Subversion would call the
"repository"?

For commits, I interpret your "repo" as the former, but when you said
"log-print" I interpreted it as the latter...

> 2. When the backend supports the concept, every vc-dir buffer has a
> special top-line entry that can be marked to select the entire repo.

...and especially here I'd like to really understand what you mean by
"repo", so I can understand exactly what the above-proposed behavior is.

Hope you're feeling better now,
-Karl

Re: Redesigh of the VC front end

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > 2. When the backend supports the concept, every vc-dir buffer has a
  > > special top-line entry that can be marked to select the entire repo.
  > 
  > In PCL-CVS we list subdirectories, including ".", which is hence not
  > particularly special. 

vc-dir has "." too, but it's not shown by default (one needs to set
vc-dir-show-directories to get it) because various VC operations don't
do too well when passed directories... When that is fixed, we can show
it by default.

  > But maybe there's a difference between "." and "the entire repo".

There should be some experts in various VC systems on the list. 
Can we please have an answer to for the above question?

Re: Redesigh of the VC front end

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> vc-dir has "." too, but it's not shown by default (one needs to set
> vc-dir-show-directories to get it) because various VC operations don't
> do too well when passed directories... When that is fixed, we can show
> it by default.

That's what I'm working towards.  That is, vc-dir-show-directories always
on and simply passing the directory args down to the back ends.

>   > But maybe there's a difference between "." and "the entire repo".
> 
> There should be some experts in various VC systems on the list. 
> Can we please have an answer to for the above question?

There sure is a difference.  They might be the same if "." is the 
top-level directory of the repo or checkout, but not otherwise.  

The iron law of Finagle guarantees that if we wire in the assumption
that the selection context defined by the top-level directory is the
same as the blank or global context, some back end will immediately
violate that...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Eric S. Raymond]

Karl Fogel <kfogel@red-bean.com>:
> When you say "repo", do you sometimes mean what Subversion would call
> the "working copy" and sometimes mean what Subversion would call the
> "repository"?
> 
> For commits, I interpret your "repo" as the former, but when you said
> "log-print" I interpreted it as the latter...

Your interpretation was correct.  Sorry, my terminology was sloppy.
 
> > 2. When the backend supports the concept, every vc-dir buffer has a
> > special top-line entry that can be marked to select the entire repo.
> 
> ...and especially here I'd like to really understand what you mean by
> "repo", so I can understand exactly what the above-proposed behavior is.

In Subversion's case, that would be the entire checkout.  So, for
example, you could specify "svn log ." by selecting "." and keying C-x
v l, but "svn log" by selecting the top line entry.

I believe these cases behave slighly differently in Subversion.  If I am
wrong, feel free to correct me. 

> Hope you're feeling better now,

I spent most of Monday sleeping and rehydrating, but did manage to get
a bit of refactoring work done on the mode during my brief awake
periods.  This was actually therapeutic; my morale is greatly helped
by being able to code.

It's about 0400 now and I'm hacking because I'm slept out, I've kept
down the chicken soup my wife fed me and our household symbiote has
been helpful in her usual fashion -- it's hard to feel completely
miserable with an affectionate cat purring against one's chest.  I'm
not physically back up to 100% yet, but my head is clear; I think I'll
be OK tomorrow.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[David Kastrup]

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

> I spent most of Monday sleeping and rehydrating, but did manage to get
> a bit of refactoring work done on the mode during my brief awake
> periods.  This was actually therapeutic; my morale is greatly helped
> by being able to code.

That is good to hear.  Actually, I find that when I am out sick, coding
is more fun because one has no guilty conscience picking the fun parts
instead of the ones on really should do.

And so it is doubly great to hear that you picked VC for that.

All the best, and get well.

-- 
David Kastrup

Re: Redesigh of the VC front end

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
> 
>   > 2. Otherwise, if you are in a vc dired buffer, and
>   > include-files-not-directories is non-nil, and no fileset is selected,
>   > select all files at and below directory level.
> 
> This is a wart that is used by vc-next-action for the following: if in a
> vc-dir buffer, you have a directory selected and do C-x v v what action 
> should be performed?
> If you have files selected, the decision is made based on the files state.
> For directories, then with this flag, return the list of files is
> returned and the decision based on the file state.  The VC action is
> still performed on the directory...
> Better ideas on how to handle this case are quite welcome.

Hm.  I think I see what you're driving at now.

Here's what I think is right.  We generalize vc-backend so it can take a 
directory argument, The default semantics is just: look for a backend by 
control subdirectory in the user's preference order.  But if we select a 
backend on the directory using C-u C-x v v, it should remember that.

Then we get rid of this wart.  The directory is passed to commands; 
include-files-not-directories goes away.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > 2. Otherwise, if you are in a vc dired buffer, and
> > include-files-not-directories is non-nil, and no fileset is selected,
> > select all files at and below directory level.
> 
> This is bad.  It should simply return the "file or directory under
> point".

Agreed.  I've already scheduled that change.
 
> > 2. When the backend supports the concept, every vc-dir buffer has a
> > special top-line entry that can be marked to select the entire repo.
> 
> In PCL-CVS we list subdirectories, including ".", which is hence not
> particularly special.  But maybe there's a difference between "." and
> "the entire repo".

As I've previously remarked, if we wire the two together the iron law
of perversity guarantees we will immediately discover a case in which they
have to be treated differently.

> > So the Dired code has to go, once the vc-dir code is at functional
> > parity to it.  This will take a little more work.
> 
> In many respects the vc-dir code will never be at parity with vc-dired,
> unless we make a special effort to merge it again with dired.  I.e. we
> shouldn't forget that some people liked to do dired operations from
> vc-dired.
> 
> For what it's worth, I don't think that merging the two is necessarily
> a bad idea.  But it seems terribly difficult to be able to do such
> a combined mode that's both as good as dired and as good as vc-dir.

You're probably right.  What controls my decision here is simply that 
Dired has no way to return a directory as a selection.  Given where I
want to go with the simplification of the UI, that's a showstopper.

> > that's what the user selected.  This means that file-oriented back ends
> > (SCCS, RCS, CVS) will have to do directory expansion for themselves
> > when it is needed.
> 
> Actually, CVS handles directories just fine in most respects.

If you think that's so, then I'll arrange directory expansion for 
SCCS and RCS only and wait to see if we get any CVS bug reports 
establishing that it's required for particular commands.  Since we're
all using CVS I expect any problem cases will become apparent 
pretty rapidly.

> > There is also a bit of murk around the handling of unregistered files.
> > I haven't completely thought that one out yet.  I think the code can be
> > rewritten so that filesets of unregistered files are simply passed to
> > the back end, yielding the VCS's own error for this case when the user
> > did not select 'register' as the operation.
> 
> 100% agreement, especially because there may be good reasons for the
> user to do that (e.g. if Emacs's notion of registration is buggy, or
> out-of-date, or because the backend includes special semantics for them
> (e.g. its "commit" operation may automatically add the unregistered
> files mentioned on the command line).

This will also be a near-future change.  

There's a more general point here.  Some of the VC front-end design 
is a relic of days when the VCS's own error messages were quite ugly
and uninformative.  Remember that I originally wrote this 15 years ago 
for SCCS; back then, it was good UI design to prevent the user from seeing
VCS error messages as much as possible, doing fairly strict checking of
the user's actions instead and detecting error cases at Lisp level before
going to the backend.

Nowadays the tradeoffs have changed.  Modern VCSes give much clearer
guidance when an operation is invalid, so it makes more sense to just 
shove commands at the backend and let it complain informatively when
something is not right.

Pushing unregistered files at a VCS command other than register 
is pretty clearly one of the cases we can punt.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> And so it is doubly great to hear that you picked VC for that.

VC has always been kind of special to me.  I've written other stuff
that may be more widely deployed -- you can't run a browser, for 
example, without using code from the GIF and PNG reference libraries 
that I had a hand in -- but I think of everything I've written VC is
probably the tool that is closest to hand for the most programmers.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > "Eric S. Raymond" <esr@snark.thyrsus.com> writes:
  > > 
  > >   > 2. Otherwise, if you are in a vc dired buffer, and
  > >   > include-files-not-directories is non-nil, and no fileset is selected,
  > >   > select all files at and below directory level.
  > > 
  > > This is a wart that is used by vc-next-action for the following: if in a
  > > vc-dir buffer, you have a directory selected and do C-x v v what action 
  > > should be performed?
  > > If you have files selected, the decision is made based on the files state.
  > > For directories, then with this flag, return the list of files is
  > > returned and the decision based on the file state.  The VC action is
  > > still performed on the directory...
  > > Better ideas on how to handle this case are quite welcome.
  > 
  > Hm.  I think I see what you're driving at now.
  > 
  > Here's what I think is right.  We generalize vc-backend so it can take a 
  > directory argument, The default semantics is just: look for a backend by 
  > control subdirectory in the user's preference order.  But if we select a 
  > backend on the directory using C-u C-x v v, it should remember that.

Sorry, this is not the issue described above.  The code is question is
not related to the backend, but to the vc _state_.

Incidentally, the code in vc-next-action that verifies the fileset:
    ;; Verify that the fileset is homogeneous
    [snip]
might fit better in vc-deduce-fileset (or whatever is called now).

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > vc-dir has "." too, but it's not shown by default (one needs to set
  > > vc-dir-show-directories to get it) because various VC operations don't
  > > do too well when passed directories... When that is fixed, we can show
  > > it by default.
  > 
  > That's what I'm working towards.  That is, vc-dir-show-directories always
  > on and simply passing the directory args down to the back ends.

That is already done right now.  Some backends choke when passed
directories though (one that comes to mind is vc-cvs-diff).

  > >   > But maybe there's a difference between "." and "the entire repo".
  > > 
  > > There should be some experts in various VC systems on the list. 
  > > Can we please have an answer to for the above question?
  > 
  > There sure is a difference.  They might be the same if "." is the 
  > top-level directory of the repo or checkout, but not otherwise.  

That's the confirmation that we needed then, the user has to do 
C-x v d at the top of the VC controlled tree and do operations on the
"."  there.  No other special casing needed.  That should work now
(modulo bugs in dealing with directories in various backends)

Re: Redesigh of the VC front end

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
>   > Dan Nicolaescu <dann@ics.uci.edu>:
>   > > vc-dir has "." too, but it's not shown by default (one needs to set
>   > > vc-dir-show-directories to get it) because various VC operations don't
>   > > do too well when passed directories... When that is fixed, we can show
>   > > it by default.
>   > 
>   > That's what I'm working towards.  That is, vc-dir-show-directories always
>   > on and simply passing the directory args down to the back ends.
> 
> That is already done right now.  Some backends choke when passed
> directories though (one that comes to mind is vc-cvs-diff).

Ah, that's good to know.  I know that SCCS and RCS don't do directory
arguments at all, and I believe that Subversion and everything after
handles them pretty well.  That leaves CVS as the place where support
is partial.  Do you know other CVS operations where it breaks?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> Sorry, this is not the issue described above.  The code is question is
> not related to the backend, but to the vc _state_.

Then I don't know what you're talking about.  Try again?

Note to all: I just changed vc-hooks slightly, so you probably want to
make bootstrap next time you cvs up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Paul R]

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

> Ah, that's good to know.  I know that SCCS and RCS don't do directory
> arguments at all, and I believe that Subversion and everything after
> handles them pretty well.

Mercurial does not manage directories at all, but it will not complain
if passed a directory as parameter where a file is expected. It will
silently do nothing.

-- 
      Paul

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > "Eric S. Raymond" <esr@thyrsus.com> writes:
  > > 
  > >   > Dan Nicolaescu <dann@ics.uci.edu>:
  > >   > > vc-dir has "." too, but it's not shown by default (one needs to set
  > >   > > vc-dir-show-directories to get it) because various VC operations don't
  > >   > > do too well when passed directories... When that is fixed, we can show
  > >   > > it by default.
  > >   > 
  > >   > That's what I'm working towards.  That is, vc-dir-show-directories always
  > >   > on and simply passing the directory args down to the back ends.
  > > 
  > > That is already done right now.  Some backends choke when passed
  > > directories though (one that comes to mind is vc-cvs-diff).
  > 
  > Ah, that's good to know.  I know that SCCS and RCS don't do directory
  > arguments at all, and I believe that Subversion and everything after
  > handles them pretty well.  That leaves CVS as the place where support
  > is partial.  Do you know other CVS operations where it breaks?

Note that I am not referring to CVS breaking here, it works fine with
directory arguments, but the VC backend functions don't deal well with
directories (vc-cvs-diff is such an example, but there are others too).

So the basic infrastructure for this should be functional now, but all
functions in all backends need testing to make sure they work OK, and
fix the bugs that show up.  Unfortunately I don't have the time to do
this now...

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > Sorry, this is not the issue described above.  The code is question is
  > > not related to the backend, but to the vc _state_.
  > 
  > Then I don't know what you're talking about.  Try again?

Given this vc-dir buffer:

    DIRECTORY            ./
    missing              config.h
*   DIRECTORY            b/
    edited               b/c
    DIRECTORY            m/
    missing              m/n

The directory "b/" is selected.
vc-next-action needs to decide what action should it perform, looking at
the "b/" directory by itself is not helpful, it needs to look at b/c and
then it can decide it next action is (vc-checkin "b/")

Now if "m/" is selected:

    DIRECTORY            ./
    missing              config.h
    DIRECTORY            b/
    edited               b/c
*   DIRECTORY            m/
    missing              m/n

vc-next-action should not do a vc-checkin, but something else.

Re: Redesigh of the VC front end

[Dan Nicolaescu]

Paul R <paul.r.ml@gmail.com> writes:

  > "Eric S. Raymond" <esr@thyrsus.com> writes:
  > 
  > > Ah, that's good to know.  I know that SCCS and RCS don't do directory
  > > arguments at all, and I believe that Subversion and everything after
  > > handles them pretty well.
  > 
  > Mercurial does not manage directories at all, but it will not complain
  > if passed a directory as parameter where a file is expected. It will
  > silently do nothing.

What exactly are the mercurial commands that do nothing when passed
directories?  status, log, ci and diff seem to DTRT.

Re: Redesigh of the VC front end

[Paul R]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> What exactly are the mercurial commands that do nothing when passed
> directories?  status, log, ci and diff seem to DTRT.

add, rm, status etc will iterate on any content of the folder, but do
nothing on the folder itself. IOW, if there is no content, nothing
happens.


-- 
      Paul

Re: Redesigh of the VC front end

[Dan Nicolaescu]

Paul R <paul.r.ml@gmail.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > What exactly are the mercurial commands that do nothing when passed
  > > directories?  status, log, ci and diff seem to DTRT.
  > 
  > add, rm, status etc will iterate on any content of the folder, but do
  > nothing on the folder itself. IOW, if there is no content, nothing
  > happens.

status seems to return the status of files in a subdir just fine.

hg add subdir seems to add all the files in the subdir, this is fine for
   what we want to do in VC.

hg rm subdir seems to remove all the files in the subdir, this is fine
for what we want to do in VC.

Do you have any other scenarios that might be questionable?  Precise
examples of commands/sequences of commands would be helpful.

Re: Redesigh of the VC front end

[Eric S. Raymond]

Paul R <paul.r.ml@gmail.com>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Ah, that's good to know.  I know that SCCS and RCS don't do directory
> > arguments at all, and I believe that Subversion and everything after
> > handles them pretty well.
> 
> Mercurial does not manage directories at all, but it will not complain
> if passed a directory as parameter where a file is expected. It will
> silently do nothing.

Then I have to do filename expansion there, too.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Redesigh of the VC front end

[Karl Fogel]

"Eric S. Raymond" <esr@thyrsus.com> writes:
> In Subversion's case, that would be the entire checkout.  So, for
> example, you could specify "svn log ." by selecting "." and keying C-x
> v l, but "svn log" by selecting the top line entry.
>
> I believe these cases behave slighly differently in Subversion.  If I am
> wrong, feel free to correct me. 

In Subversion, those cases should behave exactly the same always, but
you are right that they are both valid commands (in Subversion,
supplying no arguments usually results in an "implied `.'"  behavior).

Glad the cat is helping... :-).

-Karl

Re: Redesigh of the VC front end

[Dan Nicolaescu]

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

  > Paul R <paul.r.ml@gmail.com>:
  > > "Eric S. Raymond" <esr@thyrsus.com> writes:
  > > 
  > > > Ah, that's good to know.  I know that SCCS and RCS don't do directory
  > > > arguments at all, and I believe that Subversion and everything after
  > > > handles them pretty well.
  > > 
  > > Mercurial does not manage directories at all, but it will not complain
  > > if passed a directory as parameter where a file is expected. It will
  > > silently do nothing.
  > 
  > Then I have to do filename expansion there, too.

All evidence until now points to the contrary, nothing should be needed
for mercurial.

Re: Redesigh of the VC front end

[Paul R]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
>   > Paul R <paul.r.ml@gmail.com>:
>   > > "Eric S. Raymond" <esr@thyrsus.com> writes:
>   > > 
>   > > > Ah, that's good to know.  I know that SCCS and RCS don't do directory
>   > > > arguments at all, and I believe that Subversion and everything after
>   > > > handles them pretty well.
>   > > 
>   > > Mercurial does not manage directories at all, but it will not complain
>   > > if passed a directory as parameter where a file is expected. It will
>   > > silently do nothing.
>   > 
>   > Then I have to do filename expansion there, too.
>
> All evidence until now points to the contrary, nothing should be needed
> for mercurial.

Dan is right. For VC needs I can think of, mercurial can handle
directory itself and do "the right thing". My orignal post was to
point out that mercurial *infers* directories structure from the paths
of the files it handles. This seems compatible with VC usages.

-- 
      Paul

Re: Redesigh of the VC front end

[Stefan Monnier]

>> > 2. When the backend supports the concept, every vc-dir buffer has a
>> > special top-line entry that can be marked to select the entire repo.
>> 
>> In PCL-CVS we list subdirectories, including ".", which is hence not
>> particularly special. 

> vc-dir has "." too, but it's not shown by default (one needs to set
> vc-dir-show-directories to get it) because various VC operations don't
> do too well when passed directories... When that is fixed, we can show
> it by default.

The trunk is where development takes place.  We want to fix those
problem with directories, so we want to expose those bugs, not
hide them.


        Stefan

Re: Redesigh of the VC front end

[Stefan Monnier]

> That's what I'm working towards.  That is, vc-dir-show-directories always
> on and simply passing the directory args down to the back ends.

Sounds good.

>> > But maybe there's a difference between "." and "the entire repo".
>> There should be some experts in various VC systems on the list. 
>> Can we please have an answer to for the above question?
> There sure is a difference.  They might be the same if "." is the
> top-level directory of the repo or checkout, but not otherwise.

I don't think we should provide a way for the user to operate on a part
of the tree which is not shown in the buffer.  We may want to provide
a way to "cd ..", but nothing more.


        Stefan

Re: Redesigh of the VC front end

[Stefan Monnier]

> That is already done right now.  Some backends choke when passed
> directories though (one that comes to mind is vc-cvs-diff).

Sounds like a bug in vc-cvs-diff.  `cvs diff <dir>' works just
fine AFAIK.


        Stefan

Re: Redesigh of the VC front end

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > That is already done right now.  Some backends choke when passed
  > > directories though (one that comes to mind is vc-cvs-diff).
  > 
  > Sounds like a bug in vc-cvs-diff.  `cvs diff <dir>' works just
  > fine AFAIK.

Yep, that's exactly my point.  Although it's not exactly a bug, I don't
remember the exact details, it's about using some VC functions that
expect file argument on arguments that are not files... 

Re: Redesigh of the VC front end

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >> > 2. When the backend supports the concept, every vc-dir buffer has a
  > >> > special top-line entry that can be marked to select the entire repo.
  > >> 
  > >> In PCL-CVS we list subdirectories, including ".", which is hence not
  > >> particularly special. 
  > 
  > > vc-dir has "." too, but it's not shown by default (one needs to set
  > > vc-dir-show-directories to get it) because various VC operations don't
  > > do too well when passed directories... When that is fixed, we can show
  > > it by default.
  > 
  > The trunk is where development takes place.  We want to fix those
  > problem with directories, so we want to expose those bugs, not
  > hide them.

OK, I'll enable it later today.  But, unfortunately, I won't have much
time to fix potential problems...

Re: Redesigh of the VC front end

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> >> > But maybe there's a difference between "." and "the entire repo".
> >> There should be some experts in various VC systems on the list. 
> >> Can we please have an answer to for the above question?
> > There sure is a difference.  They might be the same if "." is the
> > top-level directory of the repo or checkout, but not otherwise.
> 
> I don't think we should provide a way for the user to operate on a part
> of the tree which is not shown in the buffer.  We may want to provide
> a way to "cd ..", but nothing more.

Hm.  That would be a reasonable alternative.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>