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

[Andrey]

Daniel Shahaf  писал(а) в своём письме Wed, 14 Jun  
2017 20:47:16 +0300:



The first column of `status` output reports not only the in-wc.db status
(e.g., 'A' / 'D' / 'R'), but also the on-disk status, e.g., '?' and '!'.
For example, compare how after 'svn add iota && /bin/rm iota', iota is
reported with status '!' rather than 'A'.  So I think it would make
sense to have a file that is scheduled to be deleted, but exists on
disk, to be reported as, say, a lowercase 'd'.

In mine case it's `svn remove iota && type nul > iota`
But i think this is almost the same case.

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

[Daniel Shahaf]

Andrey wrote on Wed, 14 Jun 2017 14:31 +0300:
> Bert Huijben  писал(а) в своём письме Wed, 14 Jun 2017  
> 13:29:18 +0300:
> 
> >> So, what about this issues? I see it as not opened yet. Will it be  
> >> fixed?
> >
> > It is not easy to really describe 'the issue'.
> >
> > How would you handle 'svn rm --keep-local ', where the current
> > behavior is the expected behavior.
> i think `svn status` must at least warn user that deleted file has been  
> locally replaced

The first column of `status` output reports not only the in-wc.db status
(e.g., 'A' / 'D' / 'R'), but also the on-disk status, e.g., '?' and '!'.
For example, compare how after 'svn add iota && /bin/rm iota', iota is
reported with status '!' rather than 'A'.  So I think it would make
sense to have a file that is scheduled to be deleted, but exists on
disk, to be reported as, say, a lowercase 'd'.

If we were designing from scratch, it might have been better to have
two columns — one for the on-disk status and one for the in-db status — 
so an added file that exists on disk would be 'AA' and an added file
that is missing would be 'A!', and similarly we could have ' ?' for
unversioned and 'D?' for deleted-in-db-but-exists-on-disk.  That would
have disentangled the overloaded first column.

> Backwards compatibility is important, availability to loose local changes  
> w/o a warning even more important than compatibility

We broke compatibility before, back in 1.6 when we added the seventh
column.  We can decide to do so again.

Why don't we continue this thread on dev@?  This is now a design
question, not a usage question.

Cheers,

Daniel

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

[Andrey]

Bert Huijben  писал(а) в своём письме Wed, 14 Jun 2017  
13:29:18 +0300:


So, what about this issues? I see it as not opened yet. Will it be  
fixed?


It is not easy to really describe 'the issue'.

How would you handle 'svn rm --keep-local ', where the current
behavior is the expected behavior.
i think `svn status` must at least warn user that deleted file has been  
locally replaced


In Subversion <= 1.6 versioned directories would always be available  
locally
until the delete was committed and we explicitly handled this case this  
way.




On the API level there is no real issue, as the information that  
something

exists locally is already available there...
So the thing that is missing is how to show this information from the  
'svn'

tool without breaking backwards compatibility.

Bert
Backwards compatibility is important, availability to loose local changes  
w/o a warning even more important than compatibility

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

[Bert Huijben]

> -Original Message-
> From: Andrey [mailto:an...@inbox.ru]
> Sent: woensdag 14 juni 2017 12:22
> To: users@subversion.apache.org
> Subject: Re: "svn status" does not show unversioned items been deleted but
> not committed
> 
> So, what about this issues? I see it as not opened yet. Will it be fixed?

It is not easy to really describe 'the issue'.

How would you handle 'svn rm --keep-local ', where the current
behavior is the expected behavior.

In Subversion <= 1.6 versioned directories would always be available locally
until the delete was committed and we explicitly handled this case this way.



On the API level there is no real issue, as the information that something
exists locally is already available there...
So the thing that is missing is how to show this information from the 'svn'
tool without breaking backwards compatibility.

Bert

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

[Andrey]

So, what about this issues? I see it as not opened yet. Will it be fixed?

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

[Andrey]

Stefan Sperling  писал(а) в своём письме 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.

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

[Johan Corveleyn]

On Thu, May 18, 2017 at 2:03 PM, Andrey  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

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

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

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

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

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