The VC to-do list

[Eric S. Raymond]

Dan Nicoleascu wrote a bunch of items into the to-do list of vc.el.  I
then appended some.  Here are my comments; I was originally going to
just mail Dan these privately but there are issues here on which
others might want to have design input.

(1) ;; - vc-dir-kill-dir-status-process should not be specific to dir-status,
;;   it should work for other async commands as well (pull/push/...).

Agreed.  Even the async diff code is in this category

Dan, the near term VC-specific fix for this one should probably be
yours, if you can find time to do it; I don't understand the ewoc
interface well enough yet, and there are other things I should do to
VC that are more urgent than learning ewoc.  Like item (2).

There's an entire layer of the VC front-end code that is really
independent of version control -- all the logic dealing with selection
sets, vc-dir, foreground/background command execution, and
parent-child buffer relationships.  I'm beginning to think this wants
to be factored out into its own module, sort of a generic
filesets-to-slave-commands dispatcher.  Such a thing would also be useful
for building IDE-like capabilities, for example.  It would call ewoc
to manage its selection-set buffer.

Your item 1 is really a way of pointing out that there ought to be a 
well-behaved generic command interrupt at this dispatcher level.

Hm.  I might just break vc.el in half this weekend along these lines.
But, Dan, if you see a fix for item (1) in the present organization,
don't let that stop you, because the entire fix should move over
cleanly.  It would all be in the dispatcher layer.

(2) ;; - vc-update/vc-merge should deal with VC systems that don't
;;   update/merge on a file basis, but on a whole repository basis.

There's actually a more basic design problem with the mode underlying
this, which is how the user *specifies* whole-repo operations.  I was
going to write a lengthy analysis here, but I think I'm going to ship
it to emacs-devel instead as a separate post.  Watch for a post on the
"null-fileset problem".  This one is mine to solve.  It's a bitch.

Actually, this UI design problem lives in the hypothetical dispatcher
layer I was just thinking about out loud.

(3) ;; - deal with push/pull operations.

Yes.  Not too hard once we solve the null-fileset problem, actually; 
I know what the keybindings ought to be, C-x v > and C-x v <, and the
rest is fairly straight-line coding.  I'll do it.

(4) ;; - "snapshots" should be renamed to "branches", and thoroughly reworked.

It's messier than that.  The real problem is that the present snapshot
implementations conflate two different concepts -- tags and branches.
When I originally wrote snapshot facility, it was a kluge to cope with
the apsence of repo-wide tags in SCCS.  Later, other backend aithors
co-opted those hooks to handle branching.  

This was an error but an understandable one; VCSes themselves have not
always been clear about the difference (yes, Subversion, I'm looking
at *you*).  These need to be pulled apart in VC.  I'll do it.

(5) ;; - when a file is in `conflict' state, turn on smerge-mode.

I know nothing about smerge.  This one is probably for you, Dan.

(6) ;; - figure out what to do with conflicts that are not caused by the
;;   file contents, but by metadata or other causes.

Example, please?

(7) ;; - add a generic mechanism for remembering the current branch names,
;;   display the branch name in the mode-line. Replace
;;   vc-cvs-sticky-tag with that.

Quite right.  I'll take this one.

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

(9) ;; - the *VC-log* buffer needs font-locking.

I know nothing about font-locking.  This one is probably for you, Dan.

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

That's a policy issue we can't solve with code -- or, to put it a
different way, any code solution we do will be wrong where it doesn't
match a user's policy expectations.  So I'm not going to put any
energy into trying.

(11) ;; - add a mechanism for ignoring files.

I'm not clear why.  Under what circumstances do we need this when
the VCS doesn't do it for us?

(12) ;; - When vc-next-action calls vc-checkin it could pre-fill the
;;   *VC-log* buffer with some obvious items: the list of files that
;;   were added, the list of files that were removed.  If the diff is
;;   available, maybe it could even call something like
;;   `diff-add-change-log-entries-other-window' to create a detailed
;;   skeleton for the log...

Dan, this sounds reasonable, but also like a thing for you to do because
you know what your goals here are.

(13) ;; - Set `vc-dir-insert-directories' to t and check what operations
;;   and backends do not support directory arguments and fix them.

There be dragons here.  I think we have to clean up the front-end
problems with defining filesets and the meaning of the null
fileset (in particular, when it means 'current directory')
before tackling this will really make sense.

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

(15) ;; - most vc-dir backends need more work.  They might need to
;;   provide custom headers, use the `extra' field and deal with all
;;   possible VC states.
;;
;; - add function that calls vc-dir to `find-directory-functions'.
;;
;; - vc-dir needs mouse bindings.
;;
;; - vc-dir needs more key bindings for VC actions.
;;
;; - vc-dir toolbar needs more icons.

None of these sound difficult.  It's basically a matter of defining
what's missing.

(16) ;; - vc-dir-next-line should not print an "end of buffer" message when
;;   invoked with the cursor on the last file.
;;
;; - add commands to move to the prev/next directory in vc-dir.

Relatively low-level coding issues.  Whichever one of us gets to 'em first.

(17) ;; - document vc-dir in the manual.

I'm willing to do that when the feature set stabilizes.

(18) ;; - vc-diff, vc-annotate, etc. need to deal better with unregistered
;;   files. Now that unregistered and ignored files are shown in
;;   vc-dired/vc-dir, it is possible that these commands are called
;;   for unregistered/ignored files.

Agreed.  This one shouldn't be too bad, I don't think it matters which
one of us takes it.

(19) ;; - do not default to RCS anymore when the current directory is not
;;   controlled by any VCS and the user does C-x v v

Likewise.

(20) ;; - vc-create-snapshot and vc-retrieve-snapshot should update the
;;   buffers that might be visiting the affected files.

I think this reduces to implementing vc-directory-resynch correctly for the 
vc-dir case.  And I think that's yours, Dan.

(21) ;; - Using multiple backends needs work.  Given a CVS directory with some
;;   files checked into git (but not all), using C-x v l to get a log file
;;   from a file only present in git, and then typing RET on some log entry,
;;   vc will bombs out because it wants to see the file being in CVS.
;;   Those logs should likely use a local variable to hardware the VC they
;;   are supposed to work with.

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.

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

(23) ;; - vc-dir listing needs a footer generated when it's done to make it
;; obvious that it has finished.

This is totally a ewoc interface issue.  Yours, Dan, I think.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

When all government ...in little as in great things... shall be drawn to
Washington as the center of all power; it will render powerless the checks
provided of one government on another, and will become as venal and oppressive
as the government from which we separated."     -- Thomas Jefferson, 1821