On Fri, Apr 20, 2012 at 01:16:24PM +0100, Philip Martin wrote:
> Stefan Sperling <stsp_at_elego.de> writes:
>
> > You're not arguing about inter-client effects, right? I.e. a GUI
> > client trying to update its icons while a command line client 'svn
> > status' run is updating timestamps? This situation isn't much different
> > to a command line client performing a concurrent update or commit, which
> > GUIs need to deal with anyway.
>
> It's probably OK. What about wc format auto-upgrades? In the past we
> had read-only operations that retained the old format and write
> operations that auto-upgraded. Does status auto-upgrade? Have we
> stopped auto-upgrading altogether?
I think we should stop silent auto-upgrading of working copies forever.
It has caused headaches in environments where multiple clients are installed
and software gets upgraded by admins, software update processes, etc.
I've seen a few situations (during the 1.5->1.6 timeframe) where someone
used TortoiseSVN in a working copy that was also used by eclipse, and the
eclipse project suddently stopped working. It's a nuisance especially for
users who are not even aware that an auto-upgrade happened. Many just
don't know Subversion well enough to be aware of such issues. They know
the minimum of what they need to know to get their day-to-day work done.
Such problems didn't happen during the 1.6->1.7 timeframe as far as I
can see (people got an error message and understood what was going on).
If some people want to keep auto-upgrade, let's add a prompt
("auto-upgrade this working copy? yes/no") or a knob to the client config
that advanced users can use to enable silent auto-upgrade. In which case
'svn status' would auto-upgrade when updating timestamps.
> Note that when status acquires the lock it has to repeat the timestamp
> check, it cannot be assumed that the timestamp is still broken, or that
> the file still exists, or that it is still a file, etc.
Yes, that's why I said the timestamp would need to be checked again.
Of course, node kind etc. would need to be verified again as well.
Received on 2012-04-20 14:38:55 CEST