Re: The VC to-do list

[Eric S. Raymond]

Stefan Monnier <address@hidden>:
> > (6) ;; - figure out what to do with conflicts that are not caused by the
> > ;;   file contents, but by metadata or other causes.
> 
> > Example, please?
> 
> File A gets renamed to B in one branch and to C in another and you merge
> the two branches.  Or you locally add file FOO and then pull a change
> that also adds a new file FOO, ...

Noted, added as a paradigm example to that to-do item.

> > (8) ;; - vc-diff should be able to show the diff for all files in a
> > ;;   changeset, especially for VC systems that have per repository
> > ;;   version numbers.  log-view should take advantage of this.
> 
> > I thought we were already doing this, at least insofar as I understand
> > the specification here.  What behavior is missing?
> 
> 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?

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

It is, however, true that Changelogs annoy me extremely.  SPOT violations
of all kinds make me pretty cranky, actually.

> > (14) ;; - a way to do repository wide log (instead of just per
> > ;;   file/fileset) is needed.  Doing it per directory might be enough...
> 
> > See the notes on the dispatcher and the null-fileset problem above.
> > This really has nothing to do with version-control per se, it would be
> > a UI issue with the front-end design for *anything* that has (a)
> > per-file, (b) per-directory, and (c) global operations.  How can the
> > user specify these contexts in an intuitive and consistent way?
> 
> In PCL-CVS, I used different user commands with different key-bindings
> for global operations.  Note that I only provided global operations for
> "update" and "refresh status", so maybe it's not that relevant.

Yes, the design problem is rather more difficult in the VC context.  I'm
going to write an analysis and post it sometime in the near future.  I'd
do it now, but I think the process of separating the dispatcher layer out 
of vc.el may give me insights so I'll probably do that first.
 
> I disagree.  I think it may require a lot of changes, but no code bloat
> at all.  It's just a matter of being careful of where we decide which
> backend to use.  Currently we make this decision over-and-over again at
> many different places.  And if one of those places makes a different
> decision, we have a bug.  So dealing with multiple backends is mostly
> a matter of deciding which backend to use once and forall and then
> properly preserving this info, which will eliminate the bugs.
> 
> Note that we've already seen such bugs for single-backend situations
> because one of the files selected happens to be managed by no backend,
> so we get bugs like "can't load vc-nil".  This is not some hypothetical
> problem.  The fact that it will correctly handle multi-backend
> situations is just the result of doing things right.

Persuade me by doing, please -- you or David Kastrup, I'm not picky.
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.  And less than six weeks to do
them in, if we take our freeze schedule seriously.

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

> Another important thing: merge all the status-like backend operations.
> We should remove dir-status, state, dir-state, and dir-status-files, and
> replace them with just `status' which takes a fileset and a continuation
> (like dir-status) and returns a buffer in which the process(es) are run
> (or nil if it worked synchronously).  Hopefully we can define the old
> 4 operations in term of this one.

Agreed.  I've been complaining to Dan that the backend API has gotten
warty and excessively complicated (mainly my fault, of course).  This seems a
good place to take a whack at simplifying it.  Adding your suggestion
as a to-do item...
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>