bug#9123: bug/misbehaviour in vc-next action when stealing locks

bug#9123: bug/misbehaviour in vc-next action when stealing locks

[albemarle]

The following seems like a bug or msibehaviour to me.

Context:
--------
Alice checks out (locks) file 'text'. The back-end is RCS.
Bob checkout the same file; he steals the lock.
Alice has made some changes. She saves the file and now wants to check in.
She presses C-x v v and is asked if she wants to steal the lock.  She says
'yes'.

What happens:
--------------
All her changes are lost and she is back to an unchanged (last revision) of
the file.

Expected:
----------
A warning saying that she is going to lose all her changes OR at least some
way of getting those changes back (e.g. undo). None is available at the
moment.

Note that Alice initiated 'vc-next-action' with the intention of 'check-in'
but she ended up having a 'check-out' that overwrote her file.

Feedback welcome.

A.

-- 
View this message in context: http://old.nabble.com/bug-misbehaviour-in-vc-next-action-when-stealing-locks-tp32089101p32089101.html
Sent from the Emacs - Bugs mailing list archive at Nabble.com.

bug#9123: bug/misbehaviour in vc-next action when stealing locks

[Glenn Morris]

albemarle wrote:

> The following seems like a bug or msibehaviour to me.

I'm having trouble reproducing this. Can you say which version of Emacs
this is with? Can you give a complete description of the sequence of
commands needed, starting from `emacs -q --no-site-file' when relevant?

bug#9123: bug/misbehaviour in vc-next action when stealing locks

[Kourosh Neshatian]

Hi Glenn,

The problem has been experienced in versions 22.2.1 and 23.3.1 of
Emacs.

Steps to reproduce the error:

1. Alice (user name 'alice') runs Emacs with 'emacs -q --no-site-file'

2. Alice creates a text file in the directory, say 'document.tex', writes
some text in it and saves it.

3. She runs 'vc-next-action' (C-x v v) and chooses RCS as her
backend. This creates an RCS file 'RCS/document.tex,v'.

4. Alice checks out and locks the file again by 'vc-next-action' (C-x
v v) to add/make some changes in the document.


5. Meanwhile, Bob (user name 'bob') logs in.  He has access to the RCS
directory (usually via a symbolic link). He checks out document.tex
stealing  the lock (rcs -l ...). NOTE: you don't actually need to login as a
different user to simulate this step. Simply open
'RCS/document.tex,v' and change 'alice' (your user name) under 'locks'
section to
'bob'.

6. Now, Alice has finished editing her copy; she saves the file and
runs 'vc-next-action' (to check in). Emacs will ask her if she wants
to steal the lock, she says 'yes'. What happens is that Emacs
over-writes her local copy by the last version in the
repository. Alice's changes/edits are all gone and apparently she does
not have any means to recover!


Cheers,
Kourosh



On 11 August 2011 09:13, Glenn Morris <rgm@gnu.org> wrote:
> albemarle wrote:
>
>> The following seems like a bug or msibehaviour to me.
>
> I'm having trouble reproducing this. Can you say which version of Emacs
> this is with? Can you give a complete description of the sequence of
> commands needed, starting from `emacs -q --no-site-file' when relevant?
>

bug#9123: bug/misbehaviour in vc-next action when stealing locks

[Glenn Morris]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown, Size: 2238 bytes --]


Kourosh Neshatian wrote (on Sun, 4 Sep 2011 at 15:57 +1200):

> I wonder if you could reproduce the error.

No, see below.

> > Steps to reproduce the error:
> >
> > 1. Alice (user name 'alice') runs Emacs with 'emacs -q --no-site-file'
> >
> > 2. Alice creates a text file in the directory, say 'document.tex', writes
> > some text in it and saves it.
> >
> > 3. She runs 'vc-next-action' (C-x v v) and chooses RCS as her
> > backend. This creates an RCS file 'RCS/document.tex,v'.
> >
> > 4. Alice checks out and locks the file again by 'vc-next-action' (C-x
> > v v) to add/make some changes in the document.

I did the following as normal user A:

umask 0
mkdir ~/foo
echo "test" > foo/1
emacs-23.3 -Q foo/1
C-x v v RCS RET RET  # now registered with RCS
C-x v v  # now file is checked out

> > 5. Meanwhile, Bob (user name 'bob') logs in.  He has access to the RCS
> > directory (usually via a symbolic link). He checks out document.tex
> > stealing  the lock (rcs -l ...).

I logged in as normal user B and did:
emacs-23.3 -Q ~A/foo/1

Emacs says "Note: file is write protected".

C-x v v
 steal the lock yes/no?  yes RET

A mail buffer pops up, prompting me to send an email to user A explaining
why I stole the lock. I do so.

> > 6. Now, Alice has finished editing her copy; she saves the file and
> > runs 'vc-next-action' (to check in). Emacs will ask her if she wants
> > to steal the lock, she says 'yes'. What happens is that Emacs
> > over-writes her local copy by the last version in the
> > repository. Alice's changes/edits are all gone and apparently she does
> > not have any means to recover!

Back in user A's still-running Emacs, I type some text in the still
open buffer. Emacs says:

  file changed on disk; really edit the buffer? 

I answer yes, type some text and save. Emacs says:

  file has changed since visited or saved.  Save anyway?

I answer yes. Emacs says:

  file is write-protected; try to save anyway?

I answer yes.

I then do C-x v v and try to check in the file. This fails, with an
error message that the file is locked by user B.

This was with RCS 5.7. I never notmally use RCS, maybe I am missing
something.

bug#9123: bug/misbehaviour in vc-next action when stealing locks

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> This was with RCS 5.7. I never notmally use RCS, maybe I am missing
> something.

More information was requested two years ago, but no further progress
has been made (and the problems seems to be unreproducible), so I'm
closing this bug report.  If this problem is still present, please
reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/