Re: My plans for VC mode

["Jan D." <jan.h.d@swipnet.se>]

Hi.

Do you have any plans for async checkin/commit from vc?

	Jan D.

> 22 nov 2014 kl. 14:33 skrev Eric S. Raymond <esr@snark.se>:
> 
> I have noted in previous mail that the VC code lacks a clean set of
> primitives to deal with branching.  My goal is to fix that.
> 
> In the way is the fact that the VC backend API is still something of
> a mess.  Everyone who has previously modified it (including me in 2007
> when I did the fileset rewrite) has tried to preserve backward
> compatibility to the year zero.  As a result, the upper-level code
> has never gotten completely divorced from the file-oriented back ends.
> 
> The merge command is a particular trouble spot where the back-end model
> pokes upward into what should be VCS-independent - as is revealed
> by the ";; FIXME: This is CVS/RCS/SCCS specific." in vc/vc.el.
> Because of the code that calls out, SVN merge in particular plain
> doesn't work right - it assumes RCS behavior in SVN revision numbers.
> 
> A related effect of trying to preserve backward compatibility is that
> the backend API has more entry points than it should and is harder to
> understand than it should be. I had my nose rubbed in this writing the
> support for SRC. Given the advantages of having written both VC mode
> and SRC and the freedom to modify SRC to make VC-mode happy, it was
> *way* more difficult than it should have been.
> 
> Accordingly, I have concluded that it is time to chuck backward
> compatibility and rewrite tha back-end API, simplifying as radically
> as I can and enforcing much stricter separation between the VC upper
> layer and the back ends.
> 
> This is going to break out-of-tree back ends - not in any way that is
> fundamentally difficult to fix, but it will break them. I've already had
> one polite complaint about that in email, but explained that we can't
> be stuck with the cruft and the previous design mistakes forever.
> 
> I'm explaining this, while "make bootstrap" runs to test a build,
> because it may cause some minor disruptions.  I'm a little worried
> about breaking CVS support; that back end is both the worst hairball
> in the file-oriented group (SCCS/RCS/CVS/SRC) and the one I'm least
> able to test well.  I could use some help with this if there is
> anyone on the list using vc-cvs regularly.
> 
> While I do branching I'm also going to look at removing the elaborate
> caching the older back ends use to avoid disk traffic as much as
> possible.  That made sense when I first wrote it twenty-odd years
> ago, but it's been a chronic source of TOCTOU bugs and other
> coherency problems ever since.  Disks are much faster now; it's
> probably time for the state-heuristic stuff to die.
> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> 
> The saddest life is that of a political aspirant under democracy. His
> failure is ignominious and his success is disgraceful.
>        -- H.L. Mencken