"svn status" does not show unversioned items been deleted but not committed

[Andrey]

As a result, for example, you can not say by "svn status" command which =
=

file you forgot to add.

Reproduction batch script for windows:
```
@echo off

set REPODIR=3Dtest_repo
set "REPOROOT=3D%~dp0%REPODIR%"
set "REPOURL=3Dfile:///%REPOROOT:\=3D/%"
set WCROOT=3D%REPODIR%_root

if exist "%REPOROOT%\" rmdir /S /Q "%REPOROOT%"
if exist "%WCROOT%\" rmdir /S /Q "%WCROOT%"

mkdir "%REPOROOT%"
svnadmin create "%REPOROOT%"
mkdir "%WCROOT%"

svn co "%REPOURL%" "%WCROOT%"

rem creating simple file
type nul > "%WCROOT%/file1.txt"
svn add "%WCROOT%/file1.txt"
svn ci "%WCROOT%" -m "rev1"

rem update to the head
svn up "%WCROOT%"

rem add new file to the directory but do not add it to the version contr=
ol
type nul > "%WCROOT%/file2.txt"

rem test status
echo --- svn status 1 ---
svn status "%WCROOT%"
echo ---

rem rename file
svn mv "%WCROOT%/file1.txt" "%WCROOT%/file_bubbles.txt" || goto :EOF

rem add a new file instead
type nul > "%WCROOT%/file1.txt"

rem test status again
echo --- svn status 2 ---
svn status "%WCROOT%"
echo ---

rem after this point the status output missed file1.txt file as =

unversioned file in the listing
```

The script output:
```
Checked out revision 0.
A test_repo_root\file1.txt
Adding test_repo_root\file1.txt
Transmitting file data .done
Committing transaction...
Committed revision 1.
Updating 'test_repo_root':
At revision 1.
--- svn status 1 ---
? test_repo_root\file2.txt
---
A test_repo_root\file_bubbles.txt
D test_repo_root\file1.txt
--- svn status 2 ---
D test_repo_root\file1.txt

moved to test_repo_root\file_bubbles.txt

? test_repo_root\file2.txt
A + test_repo_root\file_bubbles.txt

moved from test_repo_root\file1.txt

---
```

As you see the file1.txt is missed in second status output as unversione=
d =

and so can be missed from add before a commit.

-- =

=EE=C1=D0=C9=D3=C1=CE=CF =D3 =D0=CF=CD=CF=DD=D8=C0 =D0=CF=DE=D4=CF=D7=CF=
=C7=CF =CB=CC=C9=C5=CE=D4=C1 Opera: http://www.opera.com/mail/

[Branko Čibej]

Post by Andrey
As a result, for example, you can not say by "svn status" command
which file you forgot to add.
```
@echo off
set REPODIR=test_repo
set "REPOROOT=%~dp0%REPODIR%"
set "REPOURL=file:///%REPOROOT:\=/%"
set WCROOT=%REPODIR%_root
if exist "%REPOROOT%\" rmdir /S /Q "%REPOROOT%"
if exist "%WCROOT%\" rmdir /S /Q "%WCROOT%"
mkdir "%REPOROOT%"
svnadmin create "%REPOROOT%"
mkdir "%WCROOT%"
svn co "%REPOURL%" "%WCROOT%"
rem creating simple file
type nul > "%WCROOT%/file1.txt"
svn add "%WCROOT%/file1.txt"
svn ci "%WCROOT%" -m "rev1"
rem update to the head
svn up "%WCROOT%"
rem add new file to the directory but do not add it to the version
control
type nul > "%WCROOT%/file2.txt"
rem test status
echo --- svn status 1 ---
svn status "%WCROOT%"
echo ---
rem rename file
svn mv "%WCROOT%/file1.txt" "%WCROOT%/file_bubbles.txt" || goto :EOF
rem add a new file instead
type nul > "%WCROOT%/file1.txt"
rem test status again
echo --- svn status 2 ---
svn status "%WCROOT%"
echo ---
rem after this point the status output missed file1.txt file as
unversioned file in the listing
```
```
Checked out revision 0.
A test_repo_root\file1.txt
Adding test_repo_root\file1.txt
Transmitting file data .done
Committing transaction...
Committed revision 1.
At revision 1.
--- svn status 1 ---
? test_repo_root\file2.txt
---
A test_repo_root\file_bubbles.txt
D test_repo_root\file1.txt
--- svn status 2 ---
D test_repo_root\file1.txt

moved to test_repo_root\file_bubbles.txt

? test_repo_root\file2.txt
A + test_repo_root\file_bubbles.txt

moved from test_repo_root\file1.txt

---
```
As you see the file1.txt is missed in second status output as
unversioned and so can be missed from add before a commit.

It's not unversioned, it's in the "deleted" state. You can't have both,
since you can revert the deletion.

-- Brane

[Andrey]

Post by Branko Čibej

Post by Andrey
As you see the file1.txt is missed in second status output as
unversioned and so can be missed from add before a commit.

It's not unversioned, it's in the "deleted" state. You can't have both,
since you can revert the deletion.

If i'll revert it then i'll LOSE CHANGES because the svn will remove
another file w/o warning in this case. Just because it had the same name.

However, I don't want to revert anything, i am talking about possibility
of forget to add files because they are obscured by the deletion state in
the status.

PS: Please send me a mail copy (CC) next time. You know is hard to put
everything in the answer from a raw mail in the mailing list archive.

[Johan Corveleyn]

Post by Andrey

Post by Branko Čibej

Post by Andrey
As you see the file1.txt is missed in second status output as
unversioned and so can be missed from add before a commit.

It's not unversioned, it's in the "deleted" state. You can't have both,
since you can revert the deletion.

If i'll revert it then i'll LOSE CHANGES because the svn will remove
another file w/o warning in this case. Just because it had the same name.
However, I don't want to revert anything, i am talking about possibility
of forget to add files because they are obscured by the deletion state in
the status.

Hm. If you 'svn add file1.txt' (the new file that's being hidden by
the delete), then I guess it's visible as a "replace" (R), right?

So for an uncommitted delete and add at the same path we have a
special status, R. But for an uncommitted delete + unversioned at the
same path we don't. I suppose in theory we could also show a special
status for that (like R, but then for an "unversioned replacement").
It's a special case, but doesn't sound all that far fetched.

I guess you're counting on the "unversioned detection" for instance to
get the help of TortoiseSVN for not forgetting unversioned files (in
the commit dialog it shows unversioned files and has checkboxes to add
them directly from within that dialog).

[Andrey]

Johan Corveleyn <***@gmail.com> =D0=C9=D3=C1=CC(=C1) =D7 =D3=D7=CF=A3=
=CD =D0=C9=D3=D8=CD=C5 Thu, 18 May =

Post by Johan Corveleyn

Post by Andrey

Post by Andrey
As you see the file1.txt is missed in second status output as
unversioned and so can be missed from add before a commit.

It's not unversioned, it's in the "deleted" state. You can't have bo=

th,

Post by Johan Corveleyn

Post by Andrey

since you can revert the deletion.

If i'll revert it then i'll LOSE CHANGES because the svn will remove
another file w/o warning in this case. Just because it had the same =
name.
However, I don't want to revert anything, i am talking about possibil=

ity

Post by Johan Corveleyn

Post by Andrey
of forget to add files because they are obscured by the deletion stat=

e =

Post by Johan Corveleyn

Post by Andrey
in
the status.

Hm. If you 'svn add file1.txt' (the new file that's being hidden by
the delete), then I guess it's visible as a "replace" (R), right?
So for an uncommitted delete and add at the same path we have a
special status, R. But for an uncommitted delete + unversioned at the
same path we don't. I suppose in theory we could also show a special
status for that (like R, but then for an "unversioned replacement").
It's a special case, but doesn't sound all that far fetched.
I guess you're counting on the "unversioned detection" for instance to=
get the help of TortoiseSVN for not forgetting unversioned files (in
the commit dialog it shows unversioned files and has checkboxes to add=
them directly from within that dialog).

Yes. That will be good enough. And, by the way, the TortoiseSVN counting=
=

on the SVN too. :)

[Andrey]

Post by Branko Čibej

Post by Andrey
As you see the file1.txt is missed in second status output as
unversioned and so can be missed from add before a commit.

It's not unversioned, it's in the "deleted" state. You can't have both,
since you can revert the deletion.

If i'll revert it then i'll LOSE CHANGES because the svn will remove
another file w/o warning in this case. Just because it had the same name.

However, I don't want to revert anything, i am talking about possibility
of forget to add files because they are obscured by the deletion state in
the status.

PS: Please send me a mail copy (CC) next time. You know is hard to put
everything in the answer from a raw mail in the mailing list archive.

[Stefan Sperling]

Post by Andrey
If i'll revert it then i'll LOSE CHANGES

Of course. That is the entire point of this command.

$ svn help revert
revert: Restore pristine working copy state (undo local changes).
^^^^^^^^^^^^^^^^^^^^

If that bothers you, then I would suggest you do not use it.

[Andrey]

Stefan Sperling <***@elego.de> =D0=C9=D3=C1=CC(=C1) =D7 =D3=D7=CF=A3=CD=
=D0=C9=D3=D8=CD=C5 Thu, 18 May 2017 =

Post by Stefan Sperling

Post by Andrey
If i'll revert it then i'll LOSE CHANGES

Of course. That is the entire point of this command.
$ svn help revert
revert: Restore pristine working copy state (undo local changes).
^^^^^^^^^^^^^^^^^^^^
If that bothers you, then I would suggest you do not use it.

It looses changes of a file NOT RELATED TO UNDO. It is ANOTHER file just=
=

missed to be add for commit instead of renamed one. Why the svn does =

silently erase it just because of the name collision? It is definitely a=
=

not good behavior for the svn.

[Stefan Sperling]

Post by Andrey

Post by Stefan Sperling

Post by Andrey
If i'll revert it then i'll LOSE CHANGES

Of course. That is the entire point of this command.
$ svn help revert
revert: Restore pristine working copy state (undo local changes).
^^^^^^^^^^^^^^^^^^^^
If that bothers you, then I would suggest you do not use it.

It looses changes of a file NOT RELATED TO UNDO. It is ANOTHER file just
missed to be add for commit instead of renamed one. Why the svn does
silently erase it just because of the name collision? It is definitely a not
good behavior for the svn.

The revert operation is supposed to make the working copy look like
the repository. It is a dangerous operation by definition since it
always carries a risk of losing data. No matter what we do.

That said, if other people agree with you that your scenario should
be made a special case, I won't object. But I am not convinced that
such a chance is necessary.