On Fri, 8 Apr 2005, Philip Martin wrote:
> lundblad@tigris.org writes:
>
> > Author: lundblad
> > Date: Fri Apr 8 04:25:12 2005
> > New Revision: 14031
>
> > --- trunk/subversion/clients/cmdline/main.c (original)
> > +++ trunk/subversion/clients/cmdline/main.c Fri Apr 8 04:25:12 2005
> > @@ -575,7 +575,10 @@
> > " each of which consists of a relative directory path, optional\n"
> > " revision flags, and an URL. For example\n"
> > " foo http://example.com/repos/zig\n"
> > - " foo/bar -r 1234 http://example.com/repos/zag\n"),
> > + " foo/bar -r 1234 http://example.com/repos/zag\n"
> > + " svn:needs-lock - If present, indicates that the file should be\n"
> > + " locked before it is modified. Makes the file read-only in the\n"
> > + " working copy when it is not locked."),
>
> That doesn't mention what is argueably the most important thing: that
> without a lock the file cannot be commited. The WC behaviour is all
> sort of "advisory", while the repository behaviour is "mandatory".
> It's perfectly legitimate for me to chmod and edit a file if I want to
> make changes that I have no intention of committing, but there is no
> way I can work around a missing lock and commit.
>
> How about
>
> svn:needs-lock - If present, the file must be locked when it is
> committed. The working copy file will be read-only until it is
> locked.
>
Not true. svn:needs-lock is a client-side thing. It communicates to your
fellow collegues that this file must be locked. The repository doesn't
care.
> The svn:executable text
>
> This
> property cannot be set on a directory. A non-recursive attempt
> will fail, and a recursive attempt will set the property only
> on the file children of the directory.
>
> also applies to svn:needs-lock, but I don't think we should duplicate
> it. Perhaps we should remove it from svn:executable?
>
>
In fact, it applies to all props that only are meaningful for files,
svn:mime-type, svn:eol-style, svn:keywords. But I thinik we could drop
this text. I don't think every aspect of a commands behaviour must be
documented in the help text. We could move it out of the list, making it
apply for all relevant props if anyone feels that it should stay.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 8 22:39:46 2005