[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: Jani Averbach <jaa_at_jaa.iki.fi>
Date: 2004-12-16 19:41:27 CET

On 2004-12-16 18:09+0000, Julian Foad wrote:
> Ben Collins-Sussman wrote:
> >On Dec 16, 2004, at 11:50 AM, Peter N. Lundblad wrote:
> >>Do people agree that we unlock by default and don't on --keep-locked
> >>switch? I'll assume so if I don't get massive objections:-)
> >
> >That certainly seems to be the consensus.
> As usual, I'll recommend providing explicit switches for both ways, so that
> the default need not be finalised in the first release that supports
> locking. After one release worth of experience, we may have a better idea
> of what the default should be, or whether the default should be
> configurable.

Or what about if we use our svn-users list and ask there?

   Subject: User interface survey (command line)

   You have following working copy and you are about committing it:

        first_file.txt #locked, and modified
        second_file.txt #locked, and unmodified

      svn commit ./foo

   After that, what do you expect that will happen:

   a) first_file.txt will been shown on the modified file list (on your
      commit log editor), and it is still locked after the commit.

   b) first_file.txt will been shown on the modified file list (on your
      commit log editor), and it is unlocked after the commit
      (second_file.txt will be still locked).

   c) first_file.txt and second_file.txt have been shown on the
      modified file list, and both of them have been unlocked after
      the commit (even when content of second_file.txt was unmodified).
   d) Something else, please tell us what?

Let's the masses raise their voice.

BR, Jani

Jani Averbach
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 16 19:42:46 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.