[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 14 Jun 2017 17:47:16 +0000

Andrey wrote on Wed, 14 Jun 2017 14:31 +0300:
> Bert Huijben <bert_at_qqmail.nl> писал(а) в своём письме 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 <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.

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


Received on 2017-06-14 19:47:26 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.