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
lock.
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
lock.)
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
changes.
> -----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