Greg Hudson's directory lock message implicitly brought up the issue with the
working copy being set to read-only. Somehow I missed that in my read of the
docs. So let me add it to the discussion because I'd like to see more
conversation about that.
> 2. Property as communication system
>
> When the Subversion client encounters the "svn:lock" property
> on a path (on checkout or update), it sets the working-copy
> path to a read-only state by default. This serves as a
> reminder to the user that she should lock this path before
> editing it. When a user locks the path, the Subversion
> client fetches the latest version of the file, then makes the
> working-copy path read-write. When the user releases the
> lock, or if the lock is found to be defunct (see next
> section), the Subversion client makes the path read-only
> again.
First off, I think there's a thinko in the last sentence of the paragraph. I
think it should be 'makes the path read-write' not 'read-only.' If there's no
lock present, we're back at our optimistic locking scheme. (And, part of my
dilemma comes from the fact that we're mixing optimistic and pessimistic
locking strategies.) If we don't have a svn:lock set, we're optimistic. But,
what about when it's set? How far do we represent that lock?
I think the idea of mucking with the WC state could be a bad idea. I don't
think the lock state should be implicitly represented within the WC through
the file attributes. A few reasons for this:
1) I view it as the server's job to maintain authoritatively the locks not the
clients. (The owner of the lock obviously needs to store it in *their* WC, so
they have the token.) But, only the server knows whether the lock is still
valid: even the owner's WC may be out-of-date because someone else broke the
lock while they weren't looking.
Think about disconnected operations (big advantage SVN has over CVS, VSS, and
ClearCase): the fact that there was a lock right before I got on a plane to
Boston (which I'll actually be on one in less than 24 hours) doesn't tell me
there is a lock five hours mid-flight. There's no way to know whether a lock
is valid when you are disconnected. It might be valid, or it might not.
What's the point of representing information that could be stale? Why should
we be having stale locks (or already resolved locks) stored in the WC (even if
we don't know they are stale)? I don't see the purpose in being pessimistic
here: it clashes too much with the rest of Subversion.
When I get back and run 'svn up', if I happened to touch a file that was
locked, move my local file over to '.mine' or '.backup' or whatever. And,
mark that I need to do something with it...
2) I view it as a serious impediment to work if I constantly have to deal with
locked files when I already know there's a lock but I want to merge after the
lock is complete. I'd prefer to have knowledge about the lock as deferred or
unobtrusive as possible. Tell me via 'svn info' and 'svn status.' Certainly
don't let me commit without that lock token. Make 'svn up' smart by moving my
local copy to '.mine' or '.backup' when we see that the lock has been released
and the file contents updated. Great, wonderful.
My issue becomes whether the content being locked is ultimately mergable or
not. Some of the intended cases probably aren't mergable (i.e. images).
However, there is a real big case where they *are* mergable: Word docs (in our
group's case, Frame docs and EndNote repositories).
For example, I may know someone else in my group has a lock, but I want to go
ahead and make my changes locally and then I can merge my changes *after*
they've committed and released their lock.
A real common example we have here is that we have a group meeting and we
decide to make a bunch of changes to a document as a result of this meeting.
The tasks are assigned at this meeting. One person needs to restructure the
entire document. And, say, that I am assigned to rewrite one section.
I'd want the person restructuring the document to have a lock until they are
complete with their task as that is the 'most' important one (as judged by
management). Say that person gets back to their office first and runs 'svn
lock'. I went ahead and took a bathroom break and then ran 'svn up' to update
my WC as someone was making some changes right before the meeting, so my
desktop is out-of-date.
Oops, all the files are read-only because there's an outstanding lock. Under
the current proposal, I'd have to go through and make my files readable.
Damn, that's annoying. What I *really* want is to get a R/W copy locally and
*prohibit* my checking it in until the lock is released by the person who
needs to restructure the document. After the lock is released and the file
changed, I now have two copies in my WC: the 'master' version from the
repository with the restructured document and my 'local' copy which has my
smaller (in scope) edits. I'd just want to open both copies, drag the updated
text from my 'backup' over to the 'master', hit save, and be done. Perfect
behavior then.
In closing, I think the tool should prevent me from checking in my changes
without the lock, but it shouldn't obstruct me from modifying my local copy: I
own it and should do whatever I want to it. I look back at how much I hated
RCS's behavior and I don't want to go back to that. I think the WC files
should be read-write at all times and throw messages at the client when they
try to commit to something that has an active lock. But, having read-only WC
files seems like it's going to suck. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 09:35:26 2004