Re: New VC diff for review

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> >> One of these vc-diff* functions needs to do (vc-call
> >> revision-completion-table file) like vc-version-diff does in order to get
> >> completions for versions.
> 
> > There's a conceptual problem here.  Remember that new VC operates on
> > filesets, not files.  If the fileset has more than one member, which file
> > should be used  to key into the revision completion table?
> 
> What's the problem: pass it the fileset and let the backend decide.

Ah, I see.  I didn't realize you'd added a back-end method for that.
I will modify appropriately.

> Merge problem.  I "recently" replaced the `if' form by the simpler
> `expand-file-name' call.

Yes, that's what I figured.  I've merged that change into new VC.

This is going well.  The diff is down to c.1300 lines from the original
c.2200, and it looks to me like we'll only need one more round to finish
off the merge problems.

My remaining tasks before committing the big patch are:

1, Replicate the diffing bug Dan was reporting and fix that.

2. Write the Changelog entries for the big patch.

After the merge:

3. Terminology cleanup.  At this point I'm leaning towards "working
revision" for what had previously been "workfile version" and I then
relabeled "focus version".  This has the advantage that it is parallel 
to "working copy", which is Subversion jargon that a couple of more
recent systems have kept.

4. VC-Dired speedup.  It's still slow, and (at least under Subversion 
and later systems) it doesn't have to be.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>