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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Andry
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=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
```

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 unversioned  
and so can be missed from add before a commit.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
On 17.05.2017 19:50, Andrey wrote:

> 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=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
> ```
>
> 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
> 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
Reply | Threaded
Open this post in threaded view
|

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

Andry
In reply to this post by Andry
>> 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.
Reply | Threaded
Open this post in threaded view
|

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

Andry
In reply to this post by Andry
>> 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.
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling
On Thu, May 18, 2017 at 03:09:51PM +0300, Andrey wrote:
> 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.
Reply | Threaded
Open this post in threaded view
|

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

Johan Corveleyn-3
In reply to this post by Andry
On Thu, May 18, 2017 at 2:03 PM, Andrey <[hidden email]> wrote:

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

--
Johan
Reply | Threaded
Open this post in threaded view
|

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

Andry
In reply to this post by Stefan Sperling
Stefan Sperling <[hidden email]> писал(а) в своём письме Thu, 18 May 2017  
15:52:17 +0300:

> On Thu, May 18, 2017 at 03:09:51PM +0300, Andrey wrote:
>> 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.
Reply | Threaded
Open this post in threaded view
|

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

Andry
In reply to this post by Johan Corveleyn-3
Johan Corveleyn <[hidden email]> писал(а) в своём письме Thu, 18 May  
2017 16:05:49 +0300:

> On Thu, May 18, 2017 at 2:03 PM, Andrey <[hidden email]> wrote:
>>>> 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).
>
Yes. That will be good enough. And, by the way, the TortoiseSVN counting  
on the SVN too. :)
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling
In reply to this post by Andry
On Thu, May 18, 2017 at 04:36:47PM +0300, Andrey wrote:

> Stefan Sperling <[hidden email]> писал(а) в своём письме Thu, 18 May 2017
> 15:52:17 +0300:
>
> > On Thu, May 18, 2017 at 03:09:51PM +0300, Andrey wrote:
> > > 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.