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
svn:needs-lock:
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.needs-lock
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:
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.auto
To complete the auto props it's necessary to enforce them on the server
to make sure all clients have this
set, see
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks.
>
>
> 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/*//
>
>
/Nicke
--
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