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

Re: Enforcing locks

From: Nicklas Norling <exinor_at_exinor.net>
Date: 2005-12-21 11:17:23 CET

Bernd Wechner wrote:

> It's great to see that Subversion now supports file locks. This make
> sit much more useable for binary formats that don't have useful dif
> and merge tools available yet for which version control and tracking
> is still a vital thing. Common formats in that group are binary word
> processor and spreadsheet formats for example.
> Now I've started using it and am wildly pleased, but I think one small
> feature would make it a dream and that is the ability to enforce file
> locking rather than mere support of it.
> I'm envisaging the power to say for example, that all files which
> match a particular naming pattern (which might specify path and or
> extension, a simple RE on the UNC name of the file would be fine)
> require locks.
> The requirement is typical enforced in a soft way only using the
> read-only attribute of files. Such files would essentially be made
> read-only by default, and made writeable only when an update is done
> (with a lock granted in the process). The Commit would then free the
> lock and make the file read only again. The read-only flag is
> traditional set on the first Update which creates the file (to kick
> start the cycle).
It's unclear to me if you have read about the subversion property
Does it fullfill your requirements?
Also, setting such a property on files based on RE's are supported on
the client side via auto props:
To complete the auto props it's necessary to enforce them on the server
to make sure all clients have this
set, see

> Such a model pretty much avoids conflicts altogether. For that reason
> it is useful for formats for which conflict resolution is mind
> bogglingly difficult and hence worth preventing. This is the standard
> model of products like VSS of course. Subversion adds enormous
> efficiency to processes using code and text files, but we're hoping to
> use the repository for more and more of these binary formats too, and
> siuch a strategy to minimize the risk of inadvertent conflicts which
> are hellishly difficult to resolve would be an enormous asset.
> Just a suggestion anyhow.
If you still have suggestions to make in this area I think the right
mailing list is the subversion users@ list.
TSVN is wrapping svn libs and hence can not alter what and how svn does
what it does.

> Cheers,
> */Bernd Wechner/*//

JID nicke@im.exinor.net
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Dec 25 02:24:11 2005

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

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