"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?

[Bert Huijben]

-----Original Message-----
Sent: woensdag 14 juni 2017 12:22
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 <file>', 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

[Andrey]

Bert Huijben <***@qqmail.nl> =D0=C9=D3=C1=CC(=C1) =D7 =D3=D7=CF=A3=CD =D0=
=C9=D3=D8=CD=C5 Wed, 14 Jun 2017 =

Post by Bert Huijben

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 <file>', where the current
behavior is the expected behavior.

i think `svn status` must at least warn user that deleted file has been =
=

locally replaced

Post by Bert Huijben
In Subversion <=3D 1.6 versioned directories would always be available=

=

Post by Bert Huijben
locally
until the delete was committed and we explicitly handled this case thi=

s =

Post by Bert Huijben
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 =

=

Post by Bert Huijben
'svn'
tool without breaking backwards compatibility.
Bert

Backwards compatibility is important, availability to loose local change=
s =

w/o a warning even more important than compatibility

[Daniel Shahaf]

Post by Andrey

Post by Bert Huijben

Post by Andrey
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 <file>', 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.

Post by Andrey
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

[Andrey]

Daniel Shahaf <***@daniel.shahaf.name> =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=
=B0) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=
=D0=B5 Wed, 14 Jun =

The first column of `status` output reports not only the in-wc.db stat=

us

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