[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: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-04-11 22:52:50 CEST

On Mon, 2005-04-11 at 14:11 -0400, Scott Palmer wrote:
> On Apr 11, 2005, at 12:59 PM, Brian W. Fitzpatrick wrote:
> > The salient point here (a point that we need to make abundantly clear
> > when we write the documentation for the locking functionality) is that
> > there are two parts to locking: The actual locking part (which can be
> > enforced to varying degrees by the server), and the
> > advisory/communication part (accomplished by setting:needs-lock on a
> > file).
> >
> > Until we get this documented, I think that we're going to see more
> > misunderstandings like yours--thanks for your patience. :)
> I think what threw me off is that svn:needs-lock implies that you "need
> to lock the file"... but you actually don't *need* to lock the file,
> you are just *supposed* to lock the file.

True, but svn:you-should-really-lock-this-file-before-editing-it is just
declasse. :)

> I assume also that you can choose to lock any file you wish, wether it
> has the property svn:needs-lock or not. Right?


> Making this clear in the Subversion book is obvious of course. I would
> say that it should be stated in the output of 'svn help lock/unlock' as
> well, since that is the documentation that is most likely to be read.
> (I haven't installed 1.2rc1 so I don't know what the help has to say
> for the locking commands.)

Hmmm. I think mentioning svn:needs-lock in the cmdline client help
would be nice! Anyone have any objections?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 11 22:52:19 2005

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