[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: Jim Correia <jim.correia_at_pobox.com>
Date: 2004-12-17 16:33:28 CET

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.


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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.