[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Locking] commit and unlock

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-17 01:50:07 CET

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

This is an archived mail posted to the Subversion Dev mailing list.