[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2004-10-13 18:27:03 CEST

Ben Collins-Sussman wrote:
>
> * Garrett: yes, the property might be better be called 'svn:must-lock'.
[...]
> it's just a helpful tool that admins can set on unmergable files.

Agreed that that would be better. Note that we might some time want a
property like "svn:unmergeable" that tells "svn merge" etc. whether to
try merging automatically, but this need not be directly related to the
one that controls locking.

> * 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.

Yes - fair enough.

> * "Should locking imply updating"?
[...]
> What I *don't* want to happen is
[...]
> svn: sorry, you need to 'svn up'

No-one (AFAIK) was suggesting that "svn lock" should succeed on an
out-of-date file and thus lead to this sort of nastiness. They were
only debating whether in that case it should error or do the update for you.

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

Please not two different commands for locking. I don't know whether I
want it (whichever single command we choose) to do the update or not,
but let there only be one command.

> * '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.

Yes. That's good.

> * Should lock-messages be required?
>
> People seem to agree that they shouldn't be required, but still
> discussing UIs for configuring this.

Despite them being temporary (compared to commit log messages) I think
that handling them in the same way is appropriate. There are plenty of
people who don't want supply commit log messages, and they currently
have to write '-m ""'. I believe that a far greater proportion of
people will not want to give lock messages, and if it is considered too
arduous for them to have to write '-m ""' then I think we should allow
both lock and commit messages to be configurable in the same way.

I suggest that we leave lock messages out of the initial implementation,
as there will be enough other problems to solve. I can't see any reason
not to make them a later additional feature.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 18:25:47 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.