On Mon, Jul 28, 2008 at 10:46, wbaron <Wolfgang_Baron_at_gmx.de> wrote:
> Overlay icons, properties and "check for modifications" only show the
> local lock status of files. That's ok, if you share your woking
> directory among all users, but not, if you use a server. Not instantly
> seeing the lock status will cause frustration in the team, because
> things are never what they seem to be.
>
> The only way to really see locks, is to "check for modifications" and
> then click on "Check repository". The locking information, which is
> displayed there is the one you want to see all the time, so that's the
> information, which should be updated, whenever the local status is
> being refreshed. I know this slows down display a bit, but that could
> be minimized by the cache.
The base Subversion libraries do not cache lock information. It really
isn't a good thing to attempt to cache, and it would slow things down
a lot more than you think. What happens on a slow network connection?
Or working offline entirely?
The only way to truly know lock status is to check with the
repository. As soon as that check is completed, the information is
potentially invalid as things can change. Locks are not like commits -
locks don't change the state of the repository.
I fail to see how this "breaks" teamwork. If you attempt to lock a
file that's already locked, you'll be told that it's locked and your
lock attempt will fail. If a file is locked, then an update will get
you the latest version that's in the repository - personally, I don't
care what another person's changes are until they're committed, so
what's in the repository is what's important to me.
> With an updated view on the locking situation in the repository, users
> know what they have to do before they request a lock or waist their
> time making changes, which will never get checked in. Without this
> updated view, omitting svn:needs-lock on any file is pure suicide.
If you aren't applying svn:needs-lock to files which require it, then
your issue isn't with locks but with your process, and no change to
TSVN can fix that. If you're trying to implement a lock-modify-unlock
method for your entire repository (including plain-text files which
work fine with merges), then I suggest you try using SVN the way it's
meant to be used (copy-modify-merge).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: users-help_at_tortoisesvn.tigris.org
Received on 2008-07-28 17:06:31 CEST