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

RE: RE: Re: Locking

From: Harvey, Edward <Edward.Harvey_at_patni.com>
Date: 2007-11-16 17:13:47 CET

The issue here is really just one simple thing:
Communicating the presence of someone else's lock.

Since svn is a pull (not sync or push) protocol, there's only way to be
sure a file isn't locked before you edit it: Check for lock, and/or get

However, it would be useful if someone else's lock were communicated to
you automatically, to help you avoid lost work. (Very few people will
religiously check for lock if they know 98% of the time there is no

Unfortunately, in order for this to happen, svn itself must cache the
last known lock status, and there's always the risk that the last known
lock status is now outdated. I had this discussion some months ago in
the svn dev group, and folks generally agreed it was ok to cache that
info, and the tortoisesvn folks generally agreed that if it were cached,
it would be ok to display it. But nobody seems interested in coding the

> -----Original Message-----
> From: Moore, Tom [mailto:Tom.Moore@aig.com]
> Sent: Wednesday, November 14, 2007 3:04 PM
> To: Erik Huelsmann; Bicking, David (HHoldings, IT)
> Cc: Andy Levy; users@subversion.tigris.org
> Subject: RE: Re: Locking
> >Tom argued that the information should be retrieved with update, but
> >update isn't related to locking: it may even be undesirable to run
> >update in the middle of the preparation of a commit, yet it may be
> >desirable to take out a lock. He also said "file X was
> locked since the
> >working copy got updated": there's no way to tell when a file got
> >locked (before or after update) because locks aren't attached to a
> >specific revision but to a path in the repository.
> >
> >Does that explain it?
> Actually I argued that getting the information on an update
> is one way to get it. By no means did I mean to imply it
> should be the only way.
> As for the "No way to tell", I already responded on how to do that.
> I do an update, File A is locked. The working copy flags it.
> Now obviously it was locked before I updated because I found
> it when I updated. User B unlocks the file, I do another
> update. The update code (obviously modified) notes my
> working copy's lock flag and checks the lock status on the
> file. Oh look, no lock anymore. Lock existed in working
> copy before update, lock no longer found, therefore lock was
> released before update. Simple logic.
> Reverse case. Before I do an update, file is not locked, so
> no flag is set in my working copy. The update code looks in
> the repository and sees that the file is locked. (Again
> OBVIOUSLY this requires a code mode to look for locks) A
> compare against the working copy flag on the file notes that
> the file was NOT flagged as locked in my working copy, but is
> locked in the repository, therefore the lock occurred before
> my update. Again, blindingly simple logic, it's a binary
> solution, no need for timestamps or any other complex checks.
> Tom
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 16 17:14:14 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.