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

Re: Only locks in working directory are shown, renders teamwork useless

From: wbaron <Wolfgang_Baron_at_gmx.de>
Date: Tue, 29 Jul 2008 07:24:30 -0700 (PDT)

Hi Andy,

On 28 Jul., 17:06, "Andy Levy" <andy.l..._at_gmail.com> wrote:
> On Mon, Jul 28, 2008 at 10:46, wbaron <Wolfgang_Ba..._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?

That's why I suggested timeout in both directions. If the user
requests the information in a high frequency, he is willing to wait
and the other timeout prevents things to slow down too much. As
TSVNCache is a process with man threads anyway, you would never have
to wait, but let the information be kept current in the background.

> 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.

True, but the potentially invalid information does not matter, because
if it is invalid, someone else has just locked the file very shortly
before yourself, you will accept the lock failing, although you did
not see it. However, if the lock failed, because you did not see it,
although the file was locked for a few days, you start complaining,
that you want to use a different VCS. The fact is, that TortoiseSVN
*never* displays the relevant information (unless, like noted, all
users work in the same working directory, but then you wouldn't use
SVN anyway and should think about changing your career).

> 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.

Shure, but if your locks regularly fail, although you did not see
them, you are going to hate using SVN. Doing "ToroiseSVN/Check for
modifications/Check repository" all the time is way too clumsy.

I am the one that has to bring SVN to my team and I am having trouble
finding acceptance for this shortcoming (we used VSS until now (yeah,
yuck, sorry for that bad word, but that's the way it was and I am
trying to change that)).

> > [...]
>
> [...]

Forget about that last one, you are completely right of course.

Am I reaching any developers here that might include this very nice
feature into a future release or is this the wrong place to post?
Andy, are you a TortoiseSVN developer?

---------------------------------------------------------------------
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-29 17:00:47 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.