[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-04-08 14:06:36 CEST

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.

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?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 8 14:07:23 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.