Hi all. I'm not sure where this question belongs - it may be more of a
client (Tortoise) issue. Also, just to make sure I don't waste anybody's
time, it may be a dup, or at least related to, issue 2276.
I'm trying to get everybody in our company (~30 programmers) to switch over
to Subversion. We've been using an exclusive checkout model, so of course
one of the sticking points is the locking feature. People are on board for
the copy-modify-merge philosophy in general, but we all agree that in
certain situations, the exclusive checkout model is more appropriate.
What I want to discuss is this: The current design of the lock feature
basically assumes that some files will always want to use the exclusive
model, and other will always use the copy-modify-merge model. But that's
not really the case.
The lock feature is designed to allow one person exclusive access to a file,
when his changes are "unmergable." But even text files sometimes undergo
changes that are "unmergable". For example, if I know that I'm about to
make a massive overhaul of a file, then basically my changes are not
mergeable, and the exclusive checkout model is very handy, even though for
most other changes to the same file, the copy-modify-merge model would be
better.
It's in situations like this where I foresee the Subversion lock feature
only doing half of what it really should. True, if I am going to make major
changes, then I can lock a file, and this will prevent other people from
committing changes to the file. So *I* don't lose any time. But it doesn't
prevent *them* from modifying the file and wasting their time. Ensuring
that people don't step on each others toes is not the only purpose of the
locking feature --- preventing people from wasting time making changes which
will have to be thrown away is also important benefit of exclusive
checkouts. The discussion of the locking feature in the book
(http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html)
recognizes this.
Here's the specific example that I'm seeing on my screen, and how I
discovered the basic problem: I'm using the Tortoise client (Windows shell
extension), which has the "lock owner" column. In my testing of the "lock"
feature, I didn't ever see anything in this column other than my own name.
In other words, this never shows me any locks by any other people. Not very
useful. The only way to even check what files are locked by other people,
as far as I can tell, is with the "check for modifications" dialog. But
even after doing this, the explorer view doesn't show any information.
But I don't think the problem is really Tortoise specific - I think there
are improvements to the locking mechanism that aren't client-specific. For
example, it'd be really nice if a locked file was actually made real-only in
my working copy. (Obviously, I mean a file locked by somebody *else*, not
me.) This has the same advantages as does making a file read only that has
the needs-lock property that I *don't* have locked. If I try to modify the
file, I'm probably wasting my time, since somebody else has the file locked,
presumably with "unmergable changes", so any changes I make are going to be
a waste of time. I want to know this fact as soon as possible.
Perhaps a partial solution is for the lock information to be updated to the
client as soon as possible, and then for the client to store the locking
information in the working copy. (And update the read only flag on the
effected files.) Yes, this isn't a perfect solution, since you still have
to perform some action to fetch the status from the server. There really is
no perfect solution that wouldn't require the lock operation to effectively
notify all clients immediately when a file was locked - which is obviously
not feasible. (Although we have discussed the possibility of a post-lock
script that would at least email people about the lock of files that don't
have the needs-lock property, since such situations would be the exception
rather than the rule for us.) But perhaps any time the client made any (?)
request, the lock information would be updated to the local copy.
Anyway, just wanted to start a discussion. Please redirect my inquiry to
the appropriate channel if it's misplaced. I do realize that there really
is no perfect or simple solution to this, however, some simple changes might
make the feature much more useful. I'd also be interested in implementing
this feature myself, if somebody could give me some guidance.
- Fletcher Dunn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 9 02:17:30 2005