Heads up, VC front end about to undergo major surgery

Heads up, VC front end about to undergo major surgery

[Eric S. Raymond]

I've done as much as I can by refactoring and cutting away
undergrowth.  While I'll do my best to prevent actual breakage, the
upcoming round of changes to the VC front end are likely to be
somewhat disruptive.  Please have patience over the next few days;
I expect to be through the risky part by Friday or so.

This is going to be the part where I exploit ewoc to pass directories 
down to the backends, relying on them to perform the right expansiuon
to lists of files rather that doing that at the level of the VC front
end.  (We couldn't do this when the directory browser was tied to
Dired because directories aren't first-class in Dired-land).

There are two kinds of things likely to go wrong:

(1) The behavior of the UI is going to be modified along the lines I
described in my design proposal.  The actions of some commands will
change in subtle ways; especially in edge cases like (a) no selection
set or (b) unregistered files.  You may see behaviors that, though
logically consistent, differ from what experience has led you to expect.

(2) Various backend methods may just crap out when handed a directory
instead of a file list.  It is difficult to anticipate this sort of
problem, so please complain to the list if you run afoul of one and
I'll fix it ASAP.
--
						>>esr>>

Re: Heads up, VC front end about to undergo major surgery

[Dan Nicolaescu]

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

  > I've done as much as I can by refactoring and cutting away
  > undergrowth.  While I'll do my best to prevent actual breakage, the
  > upcoming round of changes to the VC front end are likely to be
  > somewhat disruptive.  Please have patience over the next few days;
  > I expect to be through the risky part by Friday or so.
  > 
  > This is going to be the part where I exploit ewoc to pass directories 
  > down to the backends, relying on them to perform the right expansiuon
  > to lists of files rather that doing that at the level of the VC front
  > end.  (We couldn't do this when the directory browser was tied to
  > Dired because directories aren't first-class in Dired-land).

Can you please expand on what will change?  Directories are passed to VC
operations right now (and you can mark/unmark them in the UI too)

  > There are two kinds of things likely to go wrong:
  > 
  > (1) The behavior of the UI is going to be modified along the lines I
  > described in my design proposal.  The actions of some commands will
  > change in subtle ways; especially in edge cases like (a) no selection
  > set or (b) unregistered files.  You may see behaviors that, though
  > logically consistent, differ from what experience has led you to expect.
  > 
  > (2) Various backend methods may just crap out when handed a directory
  > instead of a file list.  It is difficult to anticipate this sort of
  > problem, so please complain to the list if you run afoul of one and
  > I'll fix it ASAP.

If anything goes wrong with the git backend, please contact the
maintainer.  He might already have fixes.

Re: Re: Heads up, VC front end about to undergo major surgery

[Eric S. Raymond]

Dan Nicolaescu <dann@ics.uci.edu>:
> Can you please expand on what will change?  Directories are passed to VC
> operations right now (and you can mark/unmark them in the UI too)

I'm going to get rid of as much as possible of the wacky
special-casing in vc-deduce-fileset (eliminating, if possible, the
present one required and three optional args).  As I previously noted,
it has 6 messy rules for how to compute a selection set.  I aim to
reduce that to 3.  It is not impossible that I might get it down to 2.

One user-visible difference is that there will be no more *implicit*
selection of directories in the case that no fileset is available.

I think the UI of at least one capability, vc-diff, will change
significantly.  The present interface to it is a kluge forced on us by
our previous inability to select directories.

> If anything goes wrong with the git backend, please contact the
> maintainer.  He might already have fixes.

I'm not using git for anything yet.  Thus, if anything goes wrong with the 
git backend, he is almost certain to notice it before I do.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Heads up, VC front end about to undergo major surgery

[Dan Nicolaescu]

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

  > Dan Nicolaescu <dann@ics.uci.edu>:
  > > Can you please expand on what will change?  Directories are passed to VC
  > > operations right now (and you can mark/unmark them in the UI too)
  > 
  > I'm going to get rid of as much as possible of the wacky
  > special-casing in vc-deduce-fileset (eliminating, if possible, the
  > present one required and three optional args).  As I previously noted,
  > it has 6 messy rules for how to compute a selection set.  I aim to
  > reduce that to 3.  It is not impossible that I might get it down to 2.

A suggestion: the code in vc-next-action before 
;; Do the right thing
could be moved to vc-deduce-fileset
That will eliminate the need for the INCLUDE-FILES-NOT-DIRECTORIES param.

And vc-deduce-fileset could return not only the backend and file list
like now, it could also return the state and model.