Re: The VC to-do list

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> >> Do a log on foo.el, then for one of the changes, try to get the full
> >> diff: that won't work, it'll only give you the foo.el part of that
> >> changeset, not the changes made to other files.
> 
> > It's not clear to me that this is wrong behavior, given the context
> > in which the diff was requested.  But I'm willing to be convinced.
> > What's the UI/design-level argument?
> 
> I didn't mean to say that the above is a bug.  But that the other diff
> can also be useful and that there is no way currently for VC to give you
> that.  I.e. we need both to add a way for the user to request this info,
> and a way for the backend to provide it.

Noted.

> A first step was taken by having vc-deduce-fileset return both a list of
> files and a backend.  We should then kill the `vc-call' macro
> (introduced by yours truly).

Watch this space.  I'm in the process of prying the UI machinery loose
from the backend-aware stuff, as I was musing about doing two days
ago.  At some point in the not too distant future I'm going to
refactor the hell out of vc-deduce-fileset.  

The functional goal will be to clean up the UI selection logic so that
the user can always easily select either (a) the current directory,
(b) an explicit fileset, or (c) the null (repo-wide) context.

But the way I'm likeliest to actually do this (by retaining a
reference to a backend-capabilities object) will probably blow away
vc-call and a lot of the other mutually redundant backend dispatches
presently littered through the code.

Yes, I've found defstructs.  I knew about the CL version (though I'd
never used them), but when did they make it into Emacs?  For the last
30 hours or so, my Lisp chops and my OO chops have been fusing in
strange and wonderful ways.  It's interesting to actually watch my Lisp
style mutating towards Python...but then I write very Lispy Python.

(Yes, 30 hours of almost continuous hacking with short breaks for
meals; this is also my first experiment with modafinil aka Provigil.
Yes, it's legal, and yes, my doctor approved and prescribed it, and
yes, it seems remarkably benign.)

> >> > I don't really understand stay-local or the hacks around it.  I wish
> >> > somebody else would take this one.
> >> 
> >> I think stay-local should ultimately go.  It will be replaced by
> >> a distinction between "status" and "pull --dry-run".
> 
> > I think I like that direction.  I'm not certain I understand all the
> > issues around it, though.
> 
> Stay-local was introduced by yours truly basically to let vc-cvs work
> better when the repository is far away.  The way it affects the behavior
> is that diff/log/... tend to be async rather than sync (a fairly minor
> issue so it doesn't really matter whether the user can configure it as
> long as the "default" behavior works well) and more importantly, to use
> state-heuristic (which interprets CVS/Entries) rather than running "cvs
> status".  In DVCS, "foo status" corresponds roughyl to what
> state-heurstic does (e.g. it'll tell you what you've changed but not
> what other people have done), and "cvs status" corresponds to
> "pull --dry-run" (except that "pull --dry-run" might only tell you about
> what other people have done, whereas "cvs status" will combine it with
> info about what you've done).

Keeping a copy of this for later inspection...
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>