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

Issue #1921

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-06-16 18:28:28 CEST

Issue #1921 contains a patch for adding support for the --targets
option to a bunch of 'svn' subcommands. Sounds pretty
straightforward, but I ran into a theoretical snag, and I could use
some help making a decision. The following is the last comment I
added to the issue. I *think* it gives enough information to hold a
discussion.

----------------------------------------------------------------------------

Hmm... can o' worms.

'--targets FOO' is transformed into an array of targets, one for each
line of the file FOO. So when a subcommand handler is called, it is
given two such arrays, the non-option arguments that were given on the
command-line, and the items from the FOO file.

It appears that some subcommands (like 'svn switch') merge those two
array together before doing any syntax checking, which means that you
can run:

   svn switch --targets FOO

where FOO contains:

   some-URL
   some-path

And it will work.

Other commands, like 'svn propset', however, do their syntax checking
before merging the two arrays.

So you while you can do:

   svn propset svn:mime-type image/jpeg --target FOO

where FOO contains:

   file1
   dir1/file2
   ...

you can *not* do:

   svn propset --targets FOO

where FOO contains:

   svn:mime-type
   image/jpeg
   file1
   dir1/file2
   ...

This inconsistency is certain to cause confusion if the --targets flag
becomes widely used.

Cleanliness dictates that I think that --targets should only be used
for the "vararg" portions of a subcommand's argument set (the 'svn
propset' behavior), but that still might leave some subcommands whose
required arguments exceed the shell maximum for command-line length
(which is, after all, the problem which --targets was designed to
solve). So perhaps the 'svn switch' behavior is the more useful one.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 16 18:28:29 2004

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.