Inadequate branch support in VC

[Eric S. Raymond]

Dmitry Gutov <address@hidden>:
> >But I really think we should have a set of VC
> >commands that deal with branches: create them, switch to them, remove
> >them, etc.
> 
> Indeed. Maybe less related, but we could also use a 'merge' command
> and an 'amend' command (which is a fairly normal action when working
> on a branch, and will become more important when change logs are
> generated from commit messages).

I missed Dmitri's original post, but it happens I was looking at this
part of VC just hours ago.  Motivation - I'm writing a VC back end for SRC,
and this required me to get re-acquainted with the front-end/back-end
interface.

In brief, it's a pretty messy pile.

The sort of good news: there is an amend capability.  Nothing newer than
svn supports it, though - in particular, the git back end could but does not.
(SRC wlll support it.)  It's accessed through log-view, which is ... even
more confusing than the rest of the code.

As regards branching, there was an attempt to support it directly in
just two back ends (CVS and RCS) as a bag on the side of the checkin
capability, but nothing in VC actually exercised that code.  I removed 
the unused cruft to simplify the interface and at least gesture in the
direction of proper orthogonality.  That was completely the wrong place
to try to do branch switching (but I preserved the unused CVS logic in
a comment - we will need to re-use it sometime.)

There's another checkout flag case I'm probably going to abolish on my
next pass through the code.  A revision of t is suppose to force
checkout on the current branch (vs. nil which is theoretically
checkout on trunk). But in most back ends the revision flag silently
does nothing. This was another half-baked attempt to support branching
that didn't work.

Dmitri is correct.  VC needs a set of branching primitives:
get-current-branch, set-current-branch, create-branch, delete-branch,
rename-branch.  And we need a standard way to exercise them in the
UI.  Both are presently lacking.

I also, by the way, removed the "editable" flag on the checkout
capability; where it matters (SCCS and RCS) files are now always
checked out editable.  I'm almost sure the code paths with it bound to
nil weren't actually exercised - there's been a lot of drift in this
code.

In general, the back-end interface is in severe need of attention and
a design rethink.  Again.  I think the number of code paths and
back-end methods could be seriously reduced.  Can't promise when I'll
do it, but I'm at least clearing away the rubble and detritus now.

Does anyone active on the list have a direct interest in the CVS code?
That's the one problem case that's not easy for me to test.  I could
use some help verifying that my next round of changes don't break it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>