On Dec 16, 2004, at 7:50 PM, Ben Collins-Sussman wrote:
> But the main use-case (that's been posited here over and over) is that
> the "most common" scenario is for a user to lock a whole directory
> full of things they "might" need to change. Then, after working,
> they've discovered that they've only edited half of them.
>
> * should we "be literal" and have 'svn commit' only unlock the
> edited files?
> This is unfriendly to the user. Now they have to remember to
> unlock the others.
>
> * should we "be friendly" and unlock every file we see, edited or
> not?
> This is friendly, but now we're blurring concepts and
> second-guessing users.
>
> I guess the meta-debate here is: "is this really a common scenario or
> not?" Should we be making svn "smart" just for this one use-case?
Why would someone lock a whole directory worth of things just in case?
That seems absurd to me :-)
I use Perforce as work, which supports locking. Though I rarely need it
since the majority of the files we have under Perforce revision control
are merge-able text files, when we do use locking we never gratuitously
lock just in case.
Additional Perforce requires that you "p4 edit" a file before making
changes to it. We don't go around p4 edit-ing files just in case we
have to make changes - we p4 edit them as necessary.
As far as unlock on commit, if a file has been modified it should
certainly be unlocked on commit. (I don't know if this is even up for
discussion anymore - it has been a long thread.) Looking at Perforce
for prior art, the docs for p4 lock say:
Locking files prevents all other users from submitting
changes to those files. If the files are already locked by
another user, p4 lock fails. When the user who locked a
particular file submits the file, the lock is released.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 16:34:59 2004