On 11/20/07, Harvey, Edward <Edward.Harvey@patni.com> wrote:
> (Does anybody know why, recently my mail to this list has not been
> reaching the list?)
Well, the original appeared in my mailbox, so I'm not exactly sure
what you're talking about. Did you mean you think your mail didn't
appear?
> 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.
Ok.
> Instead I'm talking about what can be done to communicate this better, to the
> average unsuspecting user.
Right. Though to some extent the average unsuspecting (uneducated
even?) may need to make a step toward the processes his/her tools
support.
> #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.)
It's not been done before because this is a very explicit choice: 'svn
status' is a read-only operation; users may have and probably really
do depend on that fact.
> #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.
Right. But any information presented to the user only has value if it
has a high chance of being correct. If not, additional work will be
required to determine correctness, which means the user could have
gone the extra mile in the first place.
> #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,
Why? Because...
> and proactively warn the user not to edit that file.
... Subversion is an implementation of the copy-modify-merge model of
version control, where you can freely modify source files. Any changes
from others will be merged when required.
> If it's a mergable
> file, they might want to edit it anyway, but that's a decision for the
> svn client and user.
Umm, right. That's exactly my point above. But it's only to the user
in sofar he/she selects the tool: after that, you're kind of stuck
with the copy-modify-merge philosophy.
> The user must also acknowledge that "repository lock token present" is
> only as accurate as the last "svn status -u"
But if it's a non-mergeable resource, it should be protected with a
lock (maybe even svn:needs-lock) and the user will be notified of any
missing locks. If it's a needs-lock file, the user will need to
acquire the lock before editing anyway.
> Programmers of svn gui clients, such as tortoisesvn, don't feel it's
> their place to cache such information,
Right. Because - as I put it above - there's no use in caching the
information: it has a high chance of being outdated and additional
steps are required by the user anyway (either 'status -u' and/or
'lock').
> because they're concerned about messing up the files in .svn/.
Sorry? Even though .svn/ is off limits, it seems more appropriate they
carefully consider the philosophy of the tool they're fronting for.
> 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.
Right.
> #4
> The user is capable of scheduling a periodic "svn status -u" if he/she
> wants to.
Sure. So can he run 'svn lock' whenever 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.
... but this is only to mask the fact that you're using a tool for
things it wasn't designed for, or that you're not using the process it
was designed for: running "svn update" works on a single file level as
well as directory structures. If you want to edit a non-mergeable file
you: svn lock and svn update that file, otherwise you're in trouble.
Running 'svn status -u' doesn't change any of that, meaning that your
proposed change will introduce additional work for the user, not less.
> #5
> If the user cannot accept a certain granularity of inaccurate cached
> lock info, the user should get lock on the file before editing.
That's not the problem: WE - the developers - don't want to present
the user inaccurate lock info. If TSVN wants to query the server for
active locks when displaying the overlays in the explorer, they're
free to do so. But that is the only option to present relevant (and
accurate) information to the user.
I'm sorry, but we do not see the value of presenting incorrect
information to the user and have actively and knowingly decided
against it. I hope this explains the as-is situation.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 20 15:35:12 2007