[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving SCCS later in vc-handled-backends

From: Dan Nicolaescu
Subject: Re: moving SCCS later in vc-handled-backends
Date: Tue, 23 Jun 2009 12:09:19 -0700 (PDT)

"Stephen J. Turnbull" <address@hidden> writes:

  > Chong Yidong writes:
  >  > "Stephen J. Turnbull" <address@hidden> 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".

Can you please give some more details here?  An example would be even better.
vc does not decide a file is controlled by some VCS just based on the
presence of a directory, it actually tries to see if that file is
controlled by that VCS.
The ordering matters when the same file is controlled by multiple VCS,
vc will choose the first one in vc-handled-backends.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]