Re: The VC to-do list

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

>> > (10) ;; - make it easier to write logs.  Maybe C-x 4 a should add to the log
>> > ;;   buffer, if one is present, instead of adding to the ChangeLog.
>> 
>> > No.  The real problem here is that the combination of Changelogs and
>> > a fileset-oriented VCS's revision history is intrinsically duplicative 
>> > and bogus, and Changelogs should be shot through the head as soon as 
>> > we migrate off CVS.
>> 
>> I don't understand this "No" since you follow it by 4 lines of text that
>> seem 100% in agreement with point (10).  Looks like just mentioning
>> "ChangeLog" hits a nerve, even when the mention is going in the
>> direction you want.

> Hm.  We must be parsing the term "log buffer" differently.  Perhaps Dan
> will unpack his proposal a bit for us.

I probably wrote this TODO item.  The log buffer is *VC-Log*.
I.e. let C-x v 4 add the log-comment directly to the *VC-Log* buffer.

> Persuade me by doing, please -- you or David Kastrup, I'm not picky.

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).

> I'm not saying that to be hostile, I've just got lots of other things
> to do to VC that I consider higher priority.

Fine by me.

>> > (22) ;; - backends that care about vc-stay-local should try to take it into
>> > ;;   account for vc-dir.  Is this likely to be useful???
>> 
>> > 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).


        Stefan