On February 03, at 2005 1:42 PM, Ben Collins-Sussman
[mailto:sussman@collab.net] wrote:
> Congrats, you've just re-derived a description of "reserved
> checkouts",
> a.k.a. "locking". It's the big new feature we're working on for svn
> 1.2. We're about 70% done with it. You can see our design stuff in
> svn's /trunk/notes/locking/ dir, and look at the code itself in
> /branches/locking/.
>
> If your company depends on serialized access to binary files,
> then you
> should wait for svn 1.2. This feature is being added for exactly the
> reasons you state: not every file is mergeable. Such files
> need to be
> changed by only one person at a time.
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"), one lock
allowed (the current svn 1.2 model), multiple locks allowed (is this the
same as "lock stealing"?), and infinite locks allowed (i.e. not locked).
The only feature that seems still missing (assuming I understand "lock
stealing" correctly) is the zero locks or "read-only" mode. Also, can you
forbid "lock stealing"?
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.
---------------------------------------------------------------------
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:24:29 2005