Re: Redesigh of the VC front end

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> > 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>