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

Re: Locking UI comments

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-10-13 17:14:47 CEST

Gee, how many threads can I juggle here?

* Garrett: yes, the property might be better be called
'svn:must-lock'. Files with this property live in a read-only state,
to serve as reminder that they're non-mergeable. Locking the file
makes it read-write, and releasing the lock makes it read-only again.
It's a system for preventing people from wasting time on unmergeable
changes. The property is not required to perform a lock; it's just a
helpful tool that admins can set on unmergable files.

* Ghudson and Philip: I'm going to start a separate thread about
directory locks. You guys are right, this opens a whole new can of
worms, and needs to be examined verrrrrrry carefully.

* Julian: Greg Stein and Fitz and I had a chat about the idea of a
working copy storing lock-tokens that belong to other people, but Greg
talked us out of that idea. First, such tokens are likely to get real
stale, real fast. Second, 'svn st -u' would show other peoples' locks,
as would 'svn info URL', and would always show the latest information.
Third, there's no serious problem here that needs solving. If a file
is mergeable, and your attempted commit fails due to a previously
unknown lock by someone else, big deal. Just merge and wait for the
lock to go away. If a file isn't mergeable, then the 'svn:must-lock'
property (and resultant read-only attribute) should have been set on
the file in the first place, to prevent you from having wasted time
editing.

* "Should locking imply updating"?

   It looks like ghudson, philip, and jerenkrantz all very much want
'lock' to not run 'update'. If so, I think we need to create a command
for the non-vc people that does this, like 'svn reserve' or something.
These managers and web developers being forced to use version-control
might understand enough to run 'svn update' once a day, but I'm pretty
confident that they won't always remember to run 'svn up' right before
or after locking something. What I *don't* want to happen is

       $ svn lock foo.doc
       ### edit
       $ svn commit foo.c
        svn: sorry, you need to 'svn up'
       $ svn up
        C foo.doc

           or

       $ svn up
        svn: warning: newer file from repository saved in
'foo.backup.doc'

It would be far, far better to teach non-techies to run 'svn reserve',
and then avoid the conflict situation completely.

* Friendlier conflicts on files with 'svn:must-lock' property.

   I agree that an interactive choice between repository vs. working
file is a bad idea, you guys win. I think we should just print a
warning and save the repos file as backup, as in my example above. If
nobody objects, I'll put that in the UI spec.

* 'svn info' shows lock-tokens and works on URLs

   So far garrett and I like this idea. Are other folks okay with that?
  I agree that it's better than adding a new subcommand.

* Should 'svn commit' release or hold lock by default?

   People are still debating this.

* Should lock-messages be required?

   People seem to agree that they shouldn't be required, but still
discussing UIs for configuring this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 17:15:26 2004

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