Justin Erenkrantz wrote:
> 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
In your scenario, the lock is not used to avoid merge conflicts
of unmergeable files (which I think is the primary job of locks),
but only to push away the task of merging from me to another person.
In your particular scenario: The person restructoring the document:
What about simply finishing their task without lock,
sending it to management, and then update/merge/commit it?
In my opinion, if files can be modified locally but cannot be merged,
then locking would be more or less useless, because it fails
the job of avoiding merge conflicts of unmergable files.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 10:57:17 2004