Disabling VC: Documentation seems inadequate.

Disabling VC: Documentation seems inadequate.

[Alan Mackenzie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 642 bytes --]

The VC (version control) bit of Emacs manual (in files.texi) doesn't
appear to say how to disable VC.  Although it can be figured out, it
takes a lot more effort than I think it should.  Many thanks to Glenn
Morris who helped me figure it out on gnu.emacs.help.

I think files.texi should be amended so that it explicitly states how to
disable VC.  The attached patch does just this.

As a matter of interest, is there any good reason why VC isn't explicitly
coded as a minor mode (with something like `global-vc-mode' analogous to
`global-font-lock-mode'), or is it just the way things are?

-- 
Alan Mackenzie (Munich, Germany)
acm@muc.de


[-- Attachment #2: ChangeLog entry --]
[-- Type: TEXT/PLAIN, Size: 98 bytes --]

2003-12-03  Alan Mackenzie  <acm@muc.de>

	* files.texi: State explicitly how to disable VC.


[-- Attachment #3: files.1.85.texi.diff --]
[-- Type: TEXT/PLAIN, Size: 1528 bytes --]

*** files.1.85.texi	Wed Dec  3 17:06:03 2003
--- files.1.85.acm.texi	Wed Dec  3 20:09:58 2003
***************
*** 1124,1129 ****
--- 1125,1134 ----
  replace SCCS, known as CSSC; if you are using SCCS and don't want to
  make the incompatible change to RCS or CVS, you can switch to CSSC.
  
+   VC is enabled by default in Emacs.  To disable it, set the
+ customizable variable @code{vc-handled-backends} to @code{nil}
+ (@pxref{Customizing VC}).
+ 
  @menu
  * Introduction to VC::  How version control works in general.
  * VC Mode Line::        How the mode line shows version control status.
***************
*** 2494,2500 ****
  control systems VC should handle.  The default value is @code{(RCS CVS
  SCCS)}, so it contains all three version systems that are currently
  supported.  If you want VC to ignore one or more of these systems,
! exclude its name from the list.
  
  The order of systems in the list is significant: when you visit a file
  registered in more than one system (@pxref{Local Version Control}),
--- 2499,2506 ----
  control systems VC should handle.  The default value is @code{(RCS CVS
  SCCS)}, so it contains all three version systems that are currently
  supported.  If you want VC to ignore one or more of these systems,
! exclude its name from the list.  To disable VC entirely, set this
! variable to @code{nil}.
  
  The order of systems in the list is significant: when you visit a file
  registered in more than one system (@pxref{Local Version Control}),

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Disabling VC: Documentation seems inadequate.

[Stefan Monnier]

> The VC (version control) bit of Emacs manual (in files.texi) doesn't
> appear to say how to disable VC.  Although it can be figured out, it
> takes a lot more effort than I think it should.  Many thanks to Glenn
> Morris who helped me figure it out on gnu.emacs.help.

I think it's even more important (although one does not prevent the other)
to make sure that users don't ever need to disable VC.

In other words, if VC gets in the way, it's a bug that should be reported
as such.


        Stefan

Re: Disabling VC: Documentation seems inadequate.

[Andre Spiegel]

On Wed, 2003-12-03 at 21:45, Alan Mackenzie wrote:

> I think files.texi should be amended so that it explicitly states how to
> disable VC.  The attached patch does just this.

Sorry for making it less clear than it should have been.  Thanks for the
patch, I'll install it.

> As a matter of interest, is there any good reason why VC isn't explicitly
> coded as a minor mode (with something like `global-vc-mode' analogous to
> `global-font-lock-mode'), or is it just the way things are?

The reason was probably that in the early days, with RCS and its strict
locking, the intention was that you should not be able to bypass VC at
all, so that VC could enforce the locking policy of RCS.  This has
changed a lot since then, mostly because locking is not used all that
much anymore, and people, including myself, have learned that Emacs
should not be overly strict in enforcing any kind of policy for the
users.

Nowadays, it is really just the way things are :-)

Just out of curiosity, what was the reason you wanted to disable VC
completely?  Perhaps there was an annoyance or a misunderstanding that
should be considered.

Re: Disabling VC: Documentation seems inadequate.

[Alan Mackenzie]

On Wed, 3 Dec 2003, Andre Spiegel wrote:

>On Wed, 2003-12-03 at 21:45, Alan Mackenzie wrote:

>> I think files.texi should be amended so that it explicitly states how
>> to disable VC.  The attached patch does just this.

>Sorry for making it less clear than it should have been.  Thanks for the
>patch, I'll install it.

Thanks!

[ .... ]

>Just out of curiosity, what was the reason you wanted to disable VC
>completely?  Perhaps there was an annoyance or a misunderstanding that
>should be considered.

For me, editing files and version control are distinct activities.  I do
all my CVSing from the command line, and prefer it this way.  I feel more
in control.

I get very emotional about this topic, and I'm not sure why.  I think
I've got hangups from some very restrictive commercial VC system I had to
use a long time ago.

Several times in the past I've done C-x C-q to make a buffer read only
(simply to stop me changing it by accident) and found to my dismay that
the file got checked in, or got error messages "can't access repository".
That such an innocent operation, toggling read-onliness, could trigger
such a drastic action (checking a file in/out) took me aback, somewhat.

Sometimes (at work rather than at play) I've just wanted, say, to
reindent somebody else's messy code temporarily (to be able to understand
it), typed C-x C-q to make the buffer writeable, and been hit with the
file being checked out.

I mentioned this in summer of 2002, and you took on the task of polling
users on the issue of what C-x C-q should do (thanks!).  It turned out
that my feeling wasn't that widespread - it was my problem.  So, of
course, I bound C-x C-q to `toggle-read-only' in my own .emacs.

But even so, in the last few weeks:
(i) Sometimes my files (checked out from SourceForge under CVS control),
get loaded into RO buffers, despite the files being writeable.  I haven't
investigated why;
(ii) Sometimes Emacs has signalled an error on C-x C-s.  This occurred on
Emacs 21.1, but seems to have been fixed for 21.3.  It happened after I'd
edited a buffer, then renamed the file to a "backup" name (e.g. mv
cc-awk.el cc-awk.191103.el) before doing C-x C-s; (I used mv rather than
cp so as to preserve the file's timestamp).

Now this is all probably "pilot error", but it's hassle which appears not
to bring me any benefit.

The basic notions about VC don't match the way I hack software  (I think
I'm talking more about VC systems which use locks rather than CVS).  I
often want to change a file _without_ checking it out - to play with it,
to see what it looks like with comments added, to test an alternative
algorithm, that sort of thing, but without impeding colleagues or leaving
the (public copy of the) file in un unstable state.  Having decided that
a change is good, THEN is the time to check the file out, make the
changes permanent, and check it in.  Emacs's VC tries to prevent me doing
things this way (if I've understood it properly).  Sometimes I want to
set a _file_ RO without it getting checked in.

In short, the copies of the source I have on my hard disk should be MY
personal copy, to play around with as I wish, unless I _explicitly_
request an update from the repository or commit changes to it.  I have no
problem with other people wanting Emacs's VC to steer them through the
processes, though.

A particularly bad thing once happened to me on a proprietary VC system.
I had made some experimental changes (after being "forced" to check out
the file first).  A colleague needed to change that file in a hurry, so I
clicked the "undo lock" button in a dialog box to give him the file.  To
my anger, that fascist VC system wiped out my changes (without asking me
first) in the process of returning the lock.

Now it's quite likely that my personal process for hacking code is
somewhat unusual, but surely Emacs exists for unusual people.  ;-)  Emacs
VC appears to hinder me personally without offering me any help.  This is
why I want to disable it.

-- 
Alan Mackenzie (Munich, Germany)
acm@muc.de

Re: Disabling VC: Documentation seems inadequate.

[Stefan Monnier]

> I mentioned this in summer of 2002, and you took on the task of polling
> users on the issue of what C-x C-q should do (thanks!).  It turned out
> that my feeling wasn't that widespread - it was my problem.  So, of
> course, I bound C-x C-q to `toggle-read-only' in my own .emacs.

Your recollection is incorrect: In Emacs-CVS C-x C-q is now bound to
toggle-read-only.

> (i) Sometimes my files (checked out from SourceForge under CVS control),
> get loaded into RO buffers, despite the files being writeable.  I haven't
> investigated why;
> (ii) Sometimes Emacs has signalled an error on C-x C-s.  This occurred on
> Emacs 21.1, but seems to have been fixed for 21.3.  It happened after I'd
> edited a buffer, then renamed the file to a "backup" name (e.g. mv
> cc-awk.el cc-awk.191103.el) before doing C-x C-s; (I used mv rather than
> cp so as to preserve the file's timestamp).

> Now this is all probably "pilot error", but it's hassle which appears not
> to bring me any benefit.

If it's related to VC and you were not using VC, then it's definitely not
a pilot error but a bug in VC (or maybe a feature, but in that case maybe
we should reconsider its classification).
So please report those problems so we can fix them.


        Stefan

Re: Disabling VC: Documentation seems inadequate.

[Andre Spiegel]

On Thu, 2003-12-04 at 13:46, Alan Mackenzie wrote:

> I mentioned this in summer of 2002, and you took on the task of polling
> users on the issue of what C-x C-q should do (thanks!).  It turned out
> that my feeling wasn't that widespread - it was my problem.  So, of
> course, I bound C-x C-q to `toggle-read-only' in my own .emacs.

The results were rather inconclusive -- there were strong advocates of
either position, both with very good reasons.  Based on this, RMS
decided salomonically that we should remove the version control meaning
of C-x C-q by default (users can rebind the key individually).  So this
concerns of yours has really been fully addressed (as Stefan already
pointed out).  The change is in Emacs CVS.

> (i) Sometimes my files (checked out from SourceForge under CVS control),
> get loaded into RO buffers, despite the files being writeable.  I haven't
> investigated why;
> (ii) Sometimes Emacs has signalled an error on C-x C-s.  This occurred on
> Emacs 21.1, but seems to have been fixed for 21.3.  It happened after I'd
> edited a buffer, then renamed the file to a "backup" name (e.g. mv
> cc-awk.el cc-awk.191103.el) before doing C-x C-s; (I used mv rather than
> cp so as to preserve the file's timestamp).

That would definitely be bugs if it were reproducible.  Please don't
hesitate to report them as such if you can find a reproducible sequence
of actions that triggers that behaviour.

> The basic notions about VC don't match the way I hack software  (I think
> I'm talking more about VC systems which use locks rather than CVS).  I
> often want to change a file _without_ checking it out - to play with it,
> to see what it looks like with comments added, to test an alternative
> algorithm, that sort of thing, but without impeding colleagues or leaving
> the (public copy of the) file in un unstable state.  Having decided that
> a change is good, THEN is the time to check the file out, make the
> changes permanent, and check it in.  Emacs's VC tries to prevent me doing
> things this way (if I've understood it properly).  Sometimes I want to
> set a _file_ RO without it getting checked in.

That's a very reasonable way to work and it is the natural approach for
"modern" systems like CVS (along with the notion that locking really
isn't necessary if developers have their own private workspace).  Also,
VC is no longer that intrusive even for systems with locking, believe me
:-).

Just the other day, I was consulting for a software development team at
a bank and introduced them to RCS (they were hesitant to use CVS because
they thought that they must absolutely have locks).  But when they
tried, it took them 15 seconds to override RCS' locking mechanism and
bring the file permissions into an inconsistent state and cause really
unpleasant effects.  After that, they decided that maybe CVS was the
better way to go, after all :-)

Hoping that you might someday turn on VC again :-)

Andre