Re: Ready to start serious work on VC mode again

[Eric S. Raymond]

David Kastrup <address@hidden>:
> > [Back ends] should be associated to buffers instead.
> 
> Or buffers should be able to override the association with a
> buffer-local binding.

You may have to write this yourself if you want it. There are two problems 
blocking a solution from me.  

One is that the mode has *other* significant design problems that
could eat all my coding time for quite a while.  One of the largest,
which I'm going to post about here in more detail shortly, is
designing a command set that has sensible behavior on both
file-oriented and repo-oriented VCSes.  Following my big rewrite the
back ends now handle this distinction just fine, but there are *nasty*
problems in the front-end design proceeding from the seemingly
innocuous question "under what circumstances do we allow
(vc-deduce-fileset) to return an empty select set, and what does it
mean when we do?".  If trying to map out the Right Thing under all the
different circumstances this comes up doesn't make your head hurt, you
haven't grasped the problem yet.

Two is that I would prefer to actively neglect
mixed-VCS-in-one-directory usage.  I've said this before and
listmembers have protested, but I think it's a classic example of
allowing the preoccupation of hackers with one complex little edge
case to do bad things to the maintainability of the rest of the code.
I'm not going to personally try to "fix" this until all the other
known bugs and wishlist issues more interesting to normal VC users are
resolved.  And I'm not going to fix it at all if the complexity
overhead of doing so turns out to be too high; I'd rip out all traces
of the incomplete mixed-VCS support instead.

So, as I said, if you want this solved, you'll probably have to dig in
and do it yourself.  And work hard at making it small and elegant,
because I think this feature has low value and my willingness to accept 
crufty code in support of it is accordingly minimal.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>