On Wed, Oct 13, 2004 at 11:14:47AM -0400, Ben Collins-Sussman wrote:
> 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.
Uh, yah. svn:lock was a crappy name if it doesn't indicate if a lock
is held, but that the file should have mandatory locking enabled.
(This answers my question to ghudson from a few minutes ago.)
> * 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.
And as ghudson said, we might be better off to split the implementation
of directory locks until after we have file locking in place.
> * 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
...
Agreed that you wouldn't want to store other people's lock tokens.
However, svn st -u (or whatever) would indicate whether a lock is held
at that moment, right? So, there is a way to see if a lock is held on
the server side?
> * "Should locking imply updating"?
...
> It would be far, far better to teach non-techies to run 'svn reserve',
> and then avoid the conflict situation completely.
Honestly, they'd use GUIs. The GUI can say, "Do you want me to update?"
right after the lock is taken.
And, remember that most non-techies are going to be using Adobe Photoshop,
Mac OS X Finder, etc, etc. They all hide the lock/unlock business from
their users.
*ahem* We are planning for the locking API to be able to be DAV-compliant,
right? =) The real non-techies aren't going to know there's Subversion.
They are just going to open it up with Photoshop...
> * 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.
Yup. I'd go with '.mine' to be consistent. And, then 'svn resolved'
could clean it up??
> * '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.
+1.
> * Should 'svn commit' release or hold lock by default?
>
> People are still debating this.
So, say you. =)
> * Should lock-messages be required?
>
> People seem to agree that they shouldn't be required, but still
> discussing UIs for configuring this.
Not required, but they should be present. I'd view it as similar to our
'svn commit' messages. -- justin
---------------------------------------------------------------------
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:45:57 2004