undo add deletes local file causing data loss

[Vajzovic, Tom]

Hi,

Correct example 1:

If I have an unversioned file, and select "Add" from the tortoisesvn context menu, then the file gets added to version control.

If I then select "Undo Add" then the file is removed from version control, but the local file is left completely alone on my filesystem.

Correct example 2:

If I have a versioned file, and select "Delete" from the tortoisesvn context menu, then the file gets removed from version control and deleted from my local filesystem.

Bug example:

If I have a versioned file and from the context menu select "Rename" and enter a new name, then the file is renamed in version control and on my local filesystem.

The renamed file is then shown with the same shell overlay as a newly added file. If I look at the tortoisesvn context menu "Delete" is not listed, but "Undo Add" is listed.

If I select "Undo add" from the context menu then file is removed from version control, AND THE LOCAL FILE IS DELETED FROM MY FILE SYSTEM. If the local file contains uncommitted changes then this causes DATA LOSS.

What should happen is the same as "Undo add" in the case of a non-renamed file: the file should be removed from version control but the local file should be left completely alone on my filesystem.

Ideally a renamed file should have both "Delete" and "Undo Add" in the context menu. Delete should delete the file, Undo Add should just remove it from version control. This is a lower priority than the main issue though, which is just that "Undo Add" should never delete a local file.

Please agree that this should be raised as a bug.

Best regards,
Tom

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3084522

To unsubscribe from this discussion, e-mail: [dev-***@tortoisesvn.tigris.org].

[Simon Large]

Post by Vajzovic, Tom
Hi,
If I have an unversioned file, and select "Add" from the tortoisesvn context menu, then the file gets added to version control.
If I then select "Undo Add" then the file is removed from version control, but the local file is left completely alone on my filesystem.
If I have a versioned file, and select "Delete" from the tortoisesvn context menu, then the file gets removed from version control and deleted from my local filesystem.
If I have a versioned file and from the context menu select "Rename" and enter a new name, then the file is renamed in version control and on my local filesystem.
The renamed file is then shown with the same shell overlay as a newly added file. If I look at the tortoisesvn context menu "Delete" is not listed, but "Undo Add" is listed.
If I select "Undo add" from the context menu then file is removed from version control, AND THE LOCAL FILE IS DELETED FROM MY FILE SYSTEM. If the local file contains uncommitted changes then this causes DATA LOSS.
What should happen is the same as "Undo add" in the case of a non-renamed file: the file should be removed from version control but the local file should be left completely alone on my filesystem.
Ideally a renamed file should have both "Delete" and "Undo Add" in the context menu. Delete should delete the file, Undo Add should just remove it from version control. This is a lower priority than the main issue though, which is just that "Undo Add" should never delete a local file.
Please agree that this should be raised as a bug.

I have raised this before some time ago.
http://svn.haxx.se/tsvn/archive-2012-02/0004.shtml

I think the argument is that it is consistent with the subversion
command line client (Undo Add == Revert), and consistent with all
other uses of Revert which also cause data loss in the same way. Maybe
it is the fact that we call it 'Undo Add' instead of Revert that makes
it seem like it should behave the same as an unversioned add.

As long as you have the recycle bin enabled then the modified file
goes there, just as it does for any other revert operation.

Simon

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3084535

To unsubscribe from this discussion, e-mail: [dev-***@tortoisesvn.tigris.org].

[Xu Hong]

And also http://svn.haxx.se/tsvn/archive-2013-10/0013.shtml

I also suggest "Undo Add" do not delete file in any case.

Post by Vajzovic, Tom

Post by Vajzovic, Tom
Hi,
If I have an unversioned file, and select "Add" from the tortoisesvn

context menu, then the file gets added to version control.

Post by Vajzovic, Tom
If I then select "Undo Add" then the file is removed from version

control, but the local file is left completely alone on my filesystem.

Post by Vajzovic, Tom
If I have a versioned file, and select "Delete" from the tortoisesvn

context menu, then the file gets removed from version control and deleted
from my local filesystem.

Post by Vajzovic, Tom
If I have a versioned file and from the context menu select "Rename" and

enter a new name, then the file is renamed in version control and on my
local filesystem.

Post by Vajzovic, Tom
The renamed file is then shown with the same shell overlay as a newly

added file. If I look at the tortoisesvn context menu "Delete" is not
listed, but "Undo Add" is listed.

Post by Vajzovic, Tom
If I select "Undo add" from the context menu then file is removed from

version control, AND THE LOCAL FILE IS DELETED FROM MY FILE SYSTEM. If the
local file contains uncommitted changes then this causes DATA LOSS.

Post by Vajzovic, Tom
What should happen is the same as "Undo add" in the case of a

non-renamed file: the file should be removed from version control but the
local file should be left completely alone on my filesystem.

Post by Vajzovic, Tom
Ideally a renamed file should have both "Delete" and "Undo Add" in the

context menu. Delete should delete the file, Undo Add should just remove
it from version control. This is a lower priority than the main issue
though, which is just that "Undo Add" should never delete a local file.

Post by Vajzovic, Tom
Please agree that this should be raised as a bug.

I have raised this before some time ago.
http://svn.haxx.se/tsvn/archive-2012-02/0004.shtml
I think the argument is that it is consistent with the subversion
command line client (Undo Add == Revert), and consistent with all
other uses of Revert which also cause data loss in the same way. Maybe
it is the fact that we call it 'Undo Add' instead of Revert that makes
it seem like it should behave the same as an unversioned add.
As long as you have the recycle bin enabled then the modified file
goes there, just as it does for any other revert operation.
Simon
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3084535
To unsubscribe from this discussion, e-mail: [

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3084595

To unsubscribe from this discussion, e-mail: [dev-***@tortoisesvn.tigris.org].

[Gunter Koenigsmann]

+1 for naming the undo add button in a way that reflects the potential
data loss:

The user might not be happy when a file he has worked on for days
suddenly disappears (as happened a collegue of mine today).

Post by Simon Large
As long as you have the recycle bin enabled then the modified file
goes there, just as it does for any other revert operation.

That might be true. But the user might not know that. The recycle bin
might not work on all types of media subversion will -
and even worse: there is always the possibility the file might just not
appear there even if there don't seem to be any reasons for this to
happen. In the case of my collegue
- the file was on the local hard drive,
- the recycle bin did contain several files that had recently been
deleted from the windows explorer
- and the "Use recycle bin when reverting" was checked in his settings
dialogue.

The problem might not even be completely tsvn's fault:
- Working in a corporate environment we have a virus scanner that
checks every file every time it is changed. But I assume using a virus
scanner and setting it up in a way that it reads files on
creation/modification to be a fairly typical use case. TSVN actually
contains code to retry some file moves after a short wait in this case.
- And windows doesn't seem to allow programs to move files while they
are still being read by a different process.
Don't know if that could be the case. If not I at least can include a
description how the problem was triggered:
1.) My collegue wrote a long report
2.) When he tried to commit it there was a tree conflict (the directory
had been renamed by somebody else)
3.) To clean up he did try to undo the add before moving it away and
adding it to the renamed directory trusting svn from long experience
that this program is designed in a way that it cannot possibly loose
data.
4.) The file disappeared, but didn't appear in the recycle bin.

The windows system was a 64-bit Windows 7 with TSVN 1.8.5

Kind regards,

Gunter.



Gunter Königsmann
R&D

Tel: [phone]
Fax: [phone]

www.semikron.com
***@semikron.com

SEMIKRON Elektronik GmbH & Co. KG
Sigmundstrasse 200, 90431 Nürnberg, Germany
Amtsgericht Nürnberg HRA 13650
Komplementär:
SEMIKRON Elektronik Verwaltungs GmbH
Amtsgericht Nürnberg HRB 21338
Geschäftsführer:
Harald Jäger
Peter Sontheimer


IMPORTANT NOTICE - The contents of this email and attachments are
confidential. If you are not the intended recipient you must not use,
copy, distribute or rely on this email and should please return it
immediately or notify us by telephone. While we take every reasonable
precaution to screen out computer viruses from emails, attachments to
this email may contain such viruses. We cannot accept liability for loss
or damage resulting from such viruses. The integrity of email across
the Internet cannot be guaranteed and SEMIKRON will not accept liability
for any claims arising as a result of the use of this medium for
transmissions by or to SEMIKRON.

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3084891

To unsubscribe from this discussion, e-mail: [dev-***@tortoisesvn.tigris.org].