Re: [PATCH] Ignore the fact that a file is versioned when -F is passed to a subcommand different then 'commit'

> Hmmm... Can you tell us a little more about the motivation? Did you
> run into a situation where you used -F <versioned_file> with some
> command other than commit, and the overeager protection got in your
> way?

In fact, I was the one who originally ran into this problem, so here's a
longer description.

In the absence of a 'propedit' command, I was storing a list of entries
for 'svn:ignore' in a file, which I was then using to set the property.
  Note that the help for the propset command says:

     Use -F (instead of PROPVAL) to get the value from a file.

Valid options:
   -F [--file] arg: read data from file ARG
   -q [--quiet]: print as little as possible
   --recursive: descend recursively

Unfortunately, the file I was setting the values from was itself under
version control (because I wanted it to exist in fresh checkouts, of
course). In this situtation, any attempt to use the -F flag to propset
results in the following error:

$ svn ps svn:ignore -F .ignore

svn_error: #21099 : <The log message file is under version control>
   Log message file is a versioned file; use `--force' to override.

This error is misleading for two reasons:

(1) It's the wrong error. The above error message is really only
applicable to the commit operation.

(2) The propset command doesn't accept the '--force' flag.

There may or may not be better ways of dealing with a multiline
properties (for instance, I suppose I could propget to a file, edit the
file, then propset, then delete the file), but there's an obvious
options processing problem here.

In fact, looking at the options processing section of cmdline/main.c, I
wonder if now wouldn't be a good time to rethink the command line
processing. Right now, it looks as if everything is being parsed in one
fell swoop, which means, among other things, that main.c has to know
*all* of the valid command line options for *all* the subcommands.

In a situation where your syntax boils down to:

   command [ common_options ] subcommand [ subcommand_options ]

Mightn't it make more sense to parse the common options and the
subcommand options seperately? You could make each subcommand
responsible for parsing its own options.

-- Lars

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006