Many times before, people have had misconceptions about what a lock is,
and how it should be handled. I'm not going to talk about what it is,
because I'm assuming the interested people already know this. Instead
I'm talking about what can be done to communicate this better, to the
average unsuspecting user.
#1
If "svn status -u" retrieves information from the server about all
individual files, such as "a newer revision exists on the server" and
"lock token present on server" it is possible for "svn status -u" to
harmlessly save that information locally. (But it's never been done
before.)
#2
If svn were built to harmlessly cache that information, it would be
useful for gui clients such as tortoisesvn to display that information
to the user. Perhaps a different icon, or the read-only bit gets set,
or however the client wants to handle it.
#3
The user must acknowledge that "a newer revision exists on the server"
will remain permanently until the next update, and therefore it could be
really useful for something like tortoisesvn to have this information,
and proactively warn the user not to edit that file. If it's a mergable
file, they might want to edit it anyway, but that's a decision for the
svn client and user.
The user must also acknowledge that "repository lock token present" is
only as accurate as the last "svn status -u"
Programmers of svn gui clients, such as tortoisesvn, don't feel it's
their place to cache such information, because they're concerned about
messing up the files in .svn/. If this information were to be cached on
the client side, it's really to be done inside of subversion itself, not
inside of tortoisesvn or whatever.
#4
The user is capable of scheduling a periodic "svn status -u" if he/she
wants to. This will really improve the communication of outdated files.
And it will reduce, but not eliminate, the possibility of inaccurate
cached lock info.
#5
If the user cannot accept a certain granularity of inaccurate cached
lock info, the user should get lock on the file before editing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 19 15:51:56 2007