moving SCCS later in vc-handled-backends

moving SCCS later in vc-handled-backends

[Dan Nicolaescu]

When opening any version controlled file that is under one of the more
modern VCs, SCCS is tried first.
Given that it's not a popular system, this is pure overhead, so it would
be better move it at the end of vc-handled-backends.
Any objection to this change:

--- vc-hooks.el  23 Jun 2009 06:35:43 -0000     1.278
+++ vc-hooks.el  23 Jun 2009 06:39:31 -0000
@@ -60,7 +60,7 @@ interpreted as hostnames."
   :type 'regexp
   :group 'vc)
 
-(defcustom vc-handled-backends '(RCS CVS SVN SCCS Bzr Git Hg Mtn Arch)
+(defcustom vc-handled-backends '(RCS CVS SVN Bzr Git Hg Mtn SCCS Arch)
   ;; RCS, CVS, SVN and SCCS come first because they are per-dir
   ;; rather than per-tree.  RCS comes first because of the multibackend
   ;; support intended to use RCS for local commits (with a remote CVS server).

Re: moving SCCS later in vc-handled-backends

[Rob Weir]

On 23 Jun 2009, Dan Nicolaescu wrote:
> When opening any version controlled file that is under one of the more
> modern VCs, SCCS is tried first.  Given that it's not a popular
> system, this is pure overhead, so it would be better move it at the
> end of vc-handled-backends.  Any objection to this change:
>
> --- vc-hooks.el  23 Jun 2009 06:35:43 -0000     1.278
> +++ vc-hooks.el  23 Jun 2009 06:39:31 -0000
> @@ -60,7 +60,7 @@ interpreted as hostnames."
> :type 'regexp
> :group 'vc)
>
> -(defcustom vc-handled-backends '(RCS CVS SVN SCCS Bzr Git Hg Mtn Arch) 
> +(defcustom vc-handled-backends '(RCS CVS SVN Bzr Git Hg Mtn SCCS Arch)
> ;; RCS, CVS, SVN and SCCS come first because they are per-dir
> ;; rather than per-tree.  RCS comes first because of the multibackend
> ;; support intended to use RCS for local commits (with a remote CVS server).

Perhaps update the comment, too (by elaborating or just removing the
reference to SCCS coming first)?

-- 
-rob

moving SCCS later in vc-handled-backends

[Stephen J. Turnbull]

Dan Nicolaescu writes:
 > 
 > When opening any version controlled file that is under one of the more
 > modern VCs, SCCS is tried first.
 > Given that it's not a popular system, this is pure overhead,
 > so it would be better move it at the end of vc-handled-backends.
 > Any objection to this change:

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.

Just deprecate it entirely, by removing it from the list.  Maybe
document that 'SCCS is an allowed element, and it should come early if
it's used.

Re: moving SCCS later in vc-handled-backends

[Chong Yidong]

"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?

Re: moving SCCS later in vc-handled-backends

[Stephen J. Turnbull]

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.

Re: moving SCCS later in vc-handled-backends

[Dan Nicolaescu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

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

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.

Re: moving SCCS later in vc-handled-backends

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 > Can you please give some more details here?

I just read the docs, which claim there is a good reason for file-
oriented VCSes to come first.  If the docs are wrong, they should be
fixed.

As far as I know this has always been rare.  The whole idea is quite
possibly obsolete according to what you say about the actual behavior
of vc, but if anybody still cares the change you're suggesting will be
a subtle change in behavior that will be intermittent and possibly
hard to diagnose.  I've found that it's almost always better to change
DWIM to "do nothing" as opposed to "do what somebody else means".

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

AFAIK it will also do this if it's controlled by no backend, too.

Re: moving SCCS later in vc-handled-backends

[Jason Rumney]

Stephen J. Turnbull wrote:
> I just read the docs, which claim there is a good reason for file-
> oriented VCSes to come first.  If the docs are wrong, they should be
> fixed.

The docs/comments mention the concurrent use of RCS and CVS, but I'm not 
sure that anyone has ever expressed a real interest in combining SCCS 
with other vc backends in this way (other than it can theoretically be 
done). These days the more common use case for multiple vc backends is 
probably combining a local distributed vc backend with a public CVS or 
SVN repository.

Re: moving SCCS later in vc-handled-backends

[Dan Nicolaescu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

  > Dan Nicolaescu writes:
  > 
  >  > Can you please give some more details here?
  > 
  > I just read the docs, which claim there is a good reason for file-
  > oriented VCSes to come first.  If the docs are wrong, they should be
  > fixed.
  > 
  > As far as I know this has always been rare.  The whole idea is quite
  > possibly obsolete according to what you say about the actual behavior
  > of vc, but if anybody still cares the change you're suggesting will be
  > a subtle change in behavior that will be intermittent and possibly
  > hard to diagnose.  I've found that it's almost always better to change
  > DWIM to "do nothing" as opposed to "do what somebody else means".

Why intermittent?  It's quite deterministic, and it matters if and only
if the same file is registered by SCCS and another backend.

SCCS by itself is rare, using both SCCS and another VCS on the same file
gotta be even less frequent.

  >  > 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.
  > 
  > AFAIK it will also do this if it's controlled by no backend, too.

True, but in that case the order of search is irrelevant the same result
if obtained all the time: no backend claims to be responsible.

Re: moving SCCS later in vc-handled-backends

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have to concur with Stephen here. *If* someone is using SCCS with an
odd file managed by RCS, it'd be better having the SCCS commit fail
loudly (and leading the user to investigate the cause) than the RCS
commit failing (nearly) silently, leading possibly to a botched backup
much further down the time line.

Note that I'm no user of RCS, much less of SCCS, so take this with the
appropriate two fists of salt.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKQdsJBcgs9XrR2kYRAj5NAJ0ewvWKl0czHe0gmTyqArt0LA/zdwCfVVXv
4cFJpAnWV8Vw/cGTd4Ip1T0=
=fku0
-----END PGP SIGNATURE-----

Re: moving SCCS later in vc-handled-backends

[Dan Nicolaescu]

tomas@tuxteam.de writes:

  > I have to concur with Stephen here. *If* someone is using SCCS with an
  > odd file managed by RCS, it'd be better having the SCCS commit fail
  > loudly (and leading the user to investigate the cause) than the RCS
  > commit failing (nearly) silently, leading possibly to a botched backup
  > much further down the time line.

Can you please describe precisely the scenario that you have in mind?
Because the above is not a problem.
It is not possible to commit at the same time files that are managed by
different backends.
More, the relative order of RCS and SCCS stays the same, so the behavior
for RCS and SCCS stays the same.

  > Note that I'm no user of RCS, much less of SCCS, so take this with the
  > appropriate two fists of salt.

Re: moving SCCS later in vc-handled-backends

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 >   > a subtle change in behavior that will be intermittent and possibly
 >   > hard to diagnose.  I've found that it's almost always better to change
 >   > DWIM to "do nothing" as opposed to "do what somebody else means".
 > 
 > Why intermittent?  It's quite deterministic,

Nondeterministic and intermittent are independent concepts.  The user
doesn't care about the former, the latter bugs her mightily.  If you
don't understand the difference, ask dictionary.com, not me.

 > and it matters if and only if the same file is registered by SCCS
 > and another backend.

That's not what the docstring for `vc-responsible-backend' says.  It
claims that there are several circumstances under which the order in
`vc-handled-backends' matters, and *none* of those involve a file that's
registered at all.  See also the documentation for `vc-transfer-file'.

 > SCCS by itself is rare, using both SCCS and another VCS on the same file
 > gotta be even less frequent.

That's why a behavior change will be only intermittently observed.

Re: moving SCCS later in vc-handled-backends

[Stefan Monnier]

>> When opening any version controlled file that is under one of the more
>> modern VCs, SCCS is tried first.
>> Given that it's not a popular system, this is pure overhead,
>> so it would be better move it at the end of vc-handled-backends.
>> Any objection to this change:

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

100% agreement.  For any non-VC files, the whole list will be traversed
anyway, so the order doesn't make much difference (if any) in terms
of performance.  If we change ordering, it should not be for
performance reasons (unless you can actually show some hard-data
demonstrating the positive effects in realistic scenarios).

We could consider removing elements from the list based on the
presence/absence of the necessary tools on the system (tho it might not
be such a great idea either, since for many backends, the tools are not
necessary to find the backend and the current revision and state, and
also because many backends can be used via Tramp).


        Stefan