[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: Reedick, Andrew <jr9445_at_ATT.COM>
Date: 2007-11-20 20:57:44 CET

> -----Original Message-----
> From: Harvey, Edward [mailto:Edward.Harvey@patni.com]
> Sent: Tuesday, November 20, 2007 9:00 AM
> To: users@subversion.tigris.org
> Subject: Communication of LOCKS and CHANGES
> (Does anybody know why, recently my mail to this list has not
> been reaching the list?)
> 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. Instead I'm talking about what can
> be done to communicate this better, to the average unsuspecting user.

So it sounds like you want to use the "Lock Communication" mechanism
described in
<http://svnbook.red-bean.com/en/1.4/svn.advanced.locking.html> or want
it to be a little more robust.

At a minimum you could tag the relevent files with svn:needs-lock. Add
a hook to update the properties on the file types/trees that need

> Programmers of svn gui clients, such as tortoisesvn, don't
> feel it's their place to cache such information, because

Why can't SVN aware apps just look for the svn:needs-lock and
periodically run a background 'status -u' to check for locks? Actually
doesn't TortoiseSVN already run 'status -u' in the background (to update
the file icons?)

> #5
> If the user cannot accept a certain granularity of inaccurate
> cached lock info, the user should get lock on the file before editing.

Which is what svn:needs-lock "enforces."

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 20 21:12:20 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.