On Dec 16, 2004, at 5:52 PM, Shawn Harrison wrote:
>
> If someone on the team _is_ stupid and gratuitously locks stuff he's
> not working on, then this is a human problem with a human solution:
> training, public shamings, reprisals, whatever. I don't like to have
> the software implement policy, because that is a passive-aggressive
> approach to life, and I've had enough of that from sysadmins for two
> lifetimes.
Heh, I agree in general...
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?
> One thing that I haven't seen discussed (I might have missed this) is
> what happens when a locally modified file is unlocked: If there are
> local changes, it would seem that the file should be committed before
> it is unlocked. So in that case I would expect "svn unlock target" to
> fail with a warning, unless I use --force.
>
Hm, that's an interesting idea. Might be friendly. But is it likely?
Will someone ever "accidentally" unlock a file without committing
first?
> Another thing that I love about Subversion is that it is extremely
> well-designed. So I realize that you guys really don't need my input.
> But I appreciate the opportunity to offer it.
Thanks for the input!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 17 01:52:22 2004