On Feb 14, 2005, at 2:21 PM, Nick Seigal wrote:
>
> I have read the docs on the svn 1.2 locking. I see that it is
> all-or-nothing, while I was suggesting a multi-lock model like MS-VSS
> where
> you could have zero locks allowed (e.g. for a read-only "tag"),
That's not about locking, that's about access-control. Use an
access-control system (like mod_authz_svn, or a pre-commit hook) to
enforce read-only-ness.
> one lock
> allowed (the current svn 1.2 model),
yes...
> multiple locks allowed (is this the
> same as "lock stealing"?),
I think you're referring to "shared locks". This model is nice in
terms of communication ("who else is editing this file right now?")...
but it doesn't solve the fundamental problem of people making
simultaneous changes to unmergable files. WebDAV has support for
shared locks, but Subversion chose not to support this feature. It's a
"nice thing", but not particularly critical. We're really only
interested in solving the "unmergable edits" problem, which is a
showstopper feature for many folks.
> and infinite locks allowed (i.e. not locked).
...he normal concurrent editing model, for mergeable files, yes.
> Also, can you
> forbid "lock stealing"?
Sure, that's why we have new hooks: 'pre-lock' and 'post-lock' and
'pre-unlock' and 'post-unlock'. The 'pre-*' hooks can prevent specific
people from creating/breaking/stealing specific locks. The 'post-*'
hooks can notify people when lock creation/breaking/stealing happens,
usually through email.
>
> I was also discussing the need to have activity tracking for files
> that are
> checked out to multiple developers. The strategy of
> first-come-first-served
> merging is not necessarily a good one. It is highly political
> sometimes. A
> developer may have been working for days on something and another may
> briefly work on something else (or, heaven forbid, the very same
> issue) that
> infringes on the same code in an incompatible way. There needs to be
> some
> pre-merge warning system that can help prevent this. I suggested
> tracking
> commits and bytes commited by file and user. I may be writing my own
> tool
> (in Python probably) to do this using hook scripts and something on the
> client side to read the current status. I am curious what you and the
> community think of this idea.
I confess, I don't understand the problem you're proposing to solve.
Maybe more detail would clarify.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 14 21:42:53 2005