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.
Cheers,
Daniel
Received on 2017-06-14 19:47:26 CEST