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

Re: Communication of LOCKS and CHANGES

From: <kmradke_at_rockwellcollins.com>
Date: 2007-11-27 00:58:32 CET

Bruce Wilson <b-svn@toomuchblue.com> wrote on 11/26/2007 04:23:45 PM:


> That being said, I think the non-lock-related part of David's
> suggestion has some merit. Noting that a given file had been
> changed on the server is useful information with IMO much less risk
> of confusing the user, even if somewhat out of date.

Just as information that a file was locked the last time you checked
is useful information to some people. Retaining no information is
not value enhancing and isn't helping to protect the users from

Making it apparent the status is valid as per the time of the working copy
update and not the time/revision of the repository would remove any
possible confusion.

As a real world example, I have had many users confused why svn
isn't showing this type of information in their working copy, since they
expected it to be a snapshot of the repository at a specific instance of
(Both repository history time and wall clock time.)

None of these users has indicated they were expecting it to be updated in
They are all smart enough to realize their working copy is a snapshot in
(Again, both repository history time AND wall clock time.)

Assuming the file isn't locked because the cache says it isn't locked is
worse than assuming the file isn't locked because you have no information
about the lock status. In either case you would have to merge your
incompatible changes and in both cases you should have been smart enough
query the server if you wanted the true almost real-time status.

Kevin R.
Received on Tue Nov 27 00:58:53 2007

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.