Re: The VC to-do list

[Stefan Monnier]

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

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

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

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

> I've already explained on-list why I don't intend to put any energy
> into this until the rest of the todo list is clear.  I (a) don't think
> it's important, and (b) do fear the code bloat it seems likely to bring.

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.

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

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.


        Stefan