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