Re: moving SCCS later in vc-handled-backends

["Stephen J. Turnbull" <stephen@xemacs.org>]

Chong Yidong writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > Yes.  This change is backward incompatible and buggy; the rationale
 > > for SCCS being in the "early" group still holds as far as I know,
 > > unless SCCS has improved its support for whole-tree commits recently.
 > 
 > I don't recall what this rationale is.  Could you elucidate?

The difference between the early group and the late group is that the
early group consists of "file-oriented" VCSes.  This means that you
can have file A under RCS and file B under SCCS in the same directory,
and vc.el will handle this just fine.  However, if you (for some
reason) have a directory checked out from CVS and one stray file in it
that is under RCS, then if CVS comes before RCS, vc will decide that
the directory is under CVS, and report the file under RCS as
"unknown", rather than "under RCS control".

git, arch, mercurial, and bazaar are even worse: if any ancestor of
the directory containing our RCS- or SCCS-controlled file is under git
control, git (and vc.el) will check parents, find the GIT_DIR in that
directory, with the same result that the SCCS-controlled file is
considered to be "unknown" according to git.

Thus, having SCCS and RCS come first allows them to coexist peacefully
with git and friends in the same hierarchy.  Apparently this feature
was desired by somebody[1].

Footnotes: 
[1]  There's a fairly common use-case in CVS.  The password file for
committers is typically kept in CVSROOT but you don't want it checked
out with the other admin files there, which are under CVS control!  So
the master copy of that file is typically kept in RCS on the admin's
workstation, in the same directory as the CVS checkout of the rest of
the control files.