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

Re: svn commit: r14031 - trunk/subversion/clients/cmdline

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-04-12 07:16:29 CEST

On Mon, 2005-04-11 at 16:35, kfogel@collab.net wrote:
> "Brian W. Fitzpatrick" <fitz@collab.net> writes:
> > True, but svn:you-should-really-lock-this-file-before-editing-it is just
> > declasse. :)
>
> "svn:wants-lock" ?

We should not lose sight of the fact that we *are* enforcing
svn:needs-lock; we're just enforcing it in the client. Most users don't
care about the difference. (Security people care about the difference,
but there is no security issue here.)

Justin wrote:
> I'd recommend that we have ship a pre-commit hook example (or
> include it in the documentation?) to have a commented out check to
> verify that svn:needs-lock property isn't present or that the
> commit has the lock.

I second Julian's "why?". If someone has endeavored to override the
client's read-only bit on the file, there is no advantage to
antagonizing them further by demanding they get a lock before committing
the file. Your subsequent explanation ("I feel that this is going to be
a common use case") doesn't explain why anyone would want this
enforcement; it only asserts that lots of people will.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 07:17:21 2005

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.