You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Rafael Garcia-Suarez <ra...@hexaflux.com> on 2002/11/06 09:51:04 UTC
svn prop* syntax weirdness
"svn help pg" lists :
usage: 1. propget PROPNAME [WC_TARGETS]
2. propget PROPNAME -r REV [URL]
First usage prints versioned prop in working copy.
Second usage prints unversioned remote prop on repos revision.
(similar notes for other prop* commands.)
(the second usage is not listed in svn(1).)
But I've not found a way to get the versioned property of a file "foo"
at a specified revision. To do this, I need to do :
svn info foo | grep Revision: | awk '{print $2}' > /tmp/r
svn up foo -r1
svn pl foo
svn up foo -r `cat /tmp/r`
while I wanted to do
svn pl foo -r1 # get the property list that foo had at rev #1
Currently this latest command returns the (unversioned) property list for
revision #1 for the repository to which the "foo" wc-path refers.
This is a problem with the syntax of the prop* commands, but
I'm not sure how to solve it. (That also why I'm not submitting
a patch to the svn.1 manpage for now.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 07, 2002 at 01:43:52AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
> >On Wed, Nov 06, 2002 at 11:44:22PM +0200, Nuutti Kotivuori wrote:
> >>Karl Fogel wrote:
> >>
> >>>Should we put the current 'propfoo -r' functionality under
> >>>'revpropfoo' or `rpropfoo' instead?
> >
> >What about 'svn propfoo --revision-prop -r NNN' ?
>
> Yes, but why the additional -r? the revision number can be a parameter
> of ther --revision-prop option, can't it?
Hmm. Possible, yes. But read this line:
$ svn propget --revision-prop 34 foo file.c
I don't want revision property "34". I want property "foo". The name of the
switch isn't conducive to putting the revision number right after it.
A better name for the switch could fix this...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Wed, Nov 06, 2002 at 11:44:22PM +0200, Nuutti Kotivuori wrote:
>
>
>>Karl Fogel wrote:
>>
>>
>>>Should we put the current 'propfoo -r' functionality under
>>>'revpropfoo' or `rpropfoo' instead?
>>>
>>>
>
>What about 'svn propfoo --revision-prop -r NNN' ?
>
Yes, but why the additional -r? the revision number can be a parameter
of ther --revision-prop option, can't it?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> If no one hugely objects to this interface, I'll file an issue for the
http://subversion.tigris.org/issues/show_bug.cgi?id=943
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=202621
--
Eric Gillespie <*> epg@pretzelnet.org
Build a fire for a man, and he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> What about 'svn propfoo --revision-prop -r NNN' ? This stuff doesn't happen
> all that often, so a longopt seems quite all right for modifying the
> behavior.
>
> If you stick with the new subcommands, definitely don't use 'rpropfoo'. That
> is a bit confusing.
The option way sounds fine to me.
If no one hugely objects to this interface, I'll file an issue for the
interface change and put it in a near milestone (but not 0.15, which
is already very close :-) ).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Nov 06, 2002 at 11:44:22PM +0200, Nuutti Kotivuori wrote:
> Karl Fogel wrote:
> > Should we put the current 'propfoo -r' functionality under
> > 'revpropfoo' or `rpropfoo' instead?
What about 'svn propfoo --revision-prop -r NNN' ? This stuff doesn't happen
all that often, so a longopt seems quite all right for modifying the
behavior.
If you stick with the new subcommands, definitely don't use 'rpropfoo'. That
is a bit confusing.
>...
> But - I think we are getting a bit heavy on the amount of commands
> used for that. After this change, the help would look like:
Agreed.
>...
> Or hmm, what about a single subcommand?
>
> ,----
> | prop (p): Manipulate versioned properties on files
> | usage: 1. prop --list [WC_TARGETS]
> | 2. prop --get PROPNAME [WC_TARGETS]
> | 3. prop --delete PROPNAME [WC_TARGETS]
> | 4. prop --edit PROPNAME [WC_TARGETS]
> | 1. prop --set PROPNAME [PROPVAL | -F VALFILE] [WC_TARGETS]
Hunh. Possibly...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 07 November 2002 20:25, Greg Hudson wrote:
> The name --revision-prop suggests that it should behave
> like a flag rather than accepting a revision argument; perhaps there's
> another name which is more suggestive of accepting an argument.
$ svn pset -r 1234 name value target --revision-prop
I don't see anything wrong with that; in fact, it makes more sense to me. The
"-r" flag will keep the current semantics of choosing a revision, and the
"--revision-prop" flag specifies that it's a revision property instead of a
normal property. If --revision-prop is set and -r is not specified, then
throw an error.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD4DBQE9y0c9hDAgUT1yirARAuLCAJ9IC/I2o8GpOqZAOF3BY+vcZd4c5wCY3w1O
yj82cw1DykKvseNIUSpNTA==
=GrQb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Nuutti Kotivuori <na...@iki.fi>.
Greg Hudson wrote:
> Since I think people have pretty much laid out the options:
>
> +1 on a --revision-prop (or whatever) option to the p* commands. I
> don't care whether it accepts a revision or if you have to use a
> separate -r. (The name --revision-prop suggests that it should
> behave like a flag rather than accepting a revision argument;
> perhaps there's another name which is more suggestive of accepting
> an argument.)
This does sound like the best solution yet. And I don't have a real
opinion either whether there's a separate revision argument or not.
> -0.5 on a unified "svn prop". I don't think we should get into the
> business of using options as subcommands instead of modifiers. If
> we really want hierarchical subcommands, we should think about "svn
> prop get", but I don't think that's really necessary.
After thinking about this myself for a while - I have to agree. If
there's a unified "svn prop", then it must be done with real
subcommands on the subcommand, not just flags. And unless we want
subcommands of subcommands and someone codes support for them, we can
just forget this option.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Greg Hudson <gh...@MIT.EDU>.
Since I think people have pretty much laid out the options:
+1 on a --revision-prop (or whatever) option to the p* commands. I
don't care whether it accepts a revision or if you have to use a
separate -r. (The name --revision-prop suggests that it should behave
like a flag rather than accepting a revision argument; perhaps there's
another name which is more suggestive of accepting an argument.)
-0.5 on a unified "svn prop". I don't think we should get into the
business of using options as subcommands instead of modifiers. If we
really want hierarchical subcommands, we should think about "svn prop
get", but I don't think that's really necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
David Summers <da...@summersoft.fay.ar.us> writes:
> > | prop (p): Manipulate versioned properties on files
> > | usage: 1. prop --list [WC_TARGETS]
> > | 2. prop --get PROPNAME [WC_TARGETS]
> > | 3. prop --delete PROPNAME [WC_TARGETS]
> > | 4. prop --edit PROPNAME [WC_TARGETS]
> > | 1. prop --set PROPNAME [PROPVAL | -F VALFILE] [WC_TARGETS]
>
> I like this idea VERY well. It is essentialy subcommands to the prop
> command.
Could work, yah. Doesn't seem vastly better or worse than separate
prop commands, IMHO. Mmmm, except that it's not as conducive to
abbreviation -- 'plist', etc -- which would be a pity for experienced
users.
I don't think we should worry *too* much about minimizing the command
set so that the output of 'svn help' is short, because
1. We're only accumulating commands over time anyway (i.e., that
output is already not short),
2. Beginners learning the tool don't learn it from that output
anyway, it's more for experienced users needing a quickref,
3. The eye automatically groups the "prop*" stuff together, so it
takes up proportionally less mental space than it occupies in
the help text.
So while neither way is an unambiguous win over the other, I would
somewhat prefer to retain the separate subcommands and just add a
--revprop or --revision-prop flag.
Anyway, I've put issue #943 into milestone 0.16, and referred to this
thread from it, since it would be good to get prop -r working soon.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Wed, 6 Nov 2002, Nuutti Kotivuori wrote:
> | propdel (pdel)
> | propedit (pedit, pe)
> | propget (pget, pg)
> | proplist (plist, pl)
> | propset (pset, ps)
> | revpropdel (rpdel)
> | revpropedit (rpedit, rpe)
> | revpropget (rpget, rpg)
> | revproplist (rplist, rpl)
> | revpropset (rpset, rps)
>
> Or hmm, what about a single subcommand?
>
> ,----
> | prop (p): Manipulate versioned properties on files
> | usage: 1. prop --list [WC_TARGETS]
> | 2. prop --get PROPNAME [WC_TARGETS]
> | 3. prop --delete PROPNAME [WC_TARGETS]
> | 4. prop --edit PROPNAME [WC_TARGETS]
> | 1. prop --set PROPNAME [PROPVAL | -F VALFILE] [WC_TARGETS]
I like this idea VERY well. It is essentialy subcommands to the prop
command.
Very easy to guess and work with (maybe without the "--"?)
Just my $0.02
--
David Wayne Summers "Linux: Because reboots are for upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Nuutti Kotivuori <na...@iki.fi>.
Karl Fogel wrote:
> Should we put the current 'propfoo -r' functionality under
> 'revpropfoo' or `rpropfoo' instead?
Well, separating those commands from the normal property setting
commands is goodness.
But - I think we are getting a bit heavy on the amount of commands
used for that. After this change, the help would look like:
,----
| Available subcommands:
| add
| checkout (co)
| cleanup
| commit (ci)
| copy (cp)
| delete (del, remove, rm)
| diff (di)
| export
| help (?, h)
| import
| info
| list (ls)
| log
| merge
| mkdir
| move (mv, rename, ren)
| propdel (pdel)
| propedit (pedit, pe)
| propget (pget, pg)
| proplist (plist, pl)
| propset (pset, ps)
| revpropdel (rpdel)
| revpropedit (rpedit, rpe)
| revpropget (rpget, rpg)
| revproplist (rplist, rpl)
| revpropset (rpset, rps)
| revert
| resolve
| status (stat, st)
| switch (sw)
| update (up)
`----
Now, already now there's quite a few of those "prop" commands already
currently, but this is getting to be a bit excessive.
Alas, I don't have a reasonable alternative.
Or hmm, what about a single subcommand?
,----
| prop (p): Manipulate versioned properties on files
| usage: 1. prop --list [WC_TARGETS]
| 2. prop --get PROPNAME [WC_TARGETS]
| 3. prop --delete PROPNAME [WC_TARGETS]
| 4. prop --edit PROPNAME [WC_TARGETS]
| 1. prop --set PROPNAME [PROPVAL | -F VALFILE] [WC_TARGETS]
|
| ...
|
`----
Hmm, dunno - does someone else have an idea?
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
cmpilato@collab.net writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
>
> > Should we put the current 'propfoo -r' functionality under
> > 'revpropfoo' or `rpropfoo' instead?
>
> That would be very CVS-y. I've got no problem with doing it that way.
I like it too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Should we put the current 'propfoo -r' functionality under
> 'revpropfoo' or `rpropfoo' instead?
That would be very CVS-y. I've got no problem with doing it that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Rafael Garcia-Suarez <rg...@wanadoo.fr>.
Karl Fogel wrote:
> I think our confusion was that overloading `-r' worked okay for
> `propset', since you could never change a property at a specified
> revision of a versioned object -- that wouldn't make sense. But then
> we carried it over into proplist and propget, where it *would* make
> sense to use -r with a versioned object. And since the overload
> doesn't work for proplist and propget, we shouldn't have used it for
> propset either.
>
> Should we put the current 'propfoo -r' functionality under
> 'revpropfoo' or `rpropfoo' instead?
This way you add 5 more commands. Plus 9 aliases (if you duplicate
the syntax of prop*).
An alternative would be to forbid -r on propdel, propedit and propset,
and to add an option to prop* to work on revprops.
Another alternative : the behavior changes depending on the argument :
a wc target or an URL. In other words :
* Forbid -r for propdel, propedit, propset [targets]
* allow it for propdel, propedit, propset [URL], to work on revprops
* Allow -r for propget and proplist :
with a target, work on "regular prop"
with an url, work on a revprop.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> I think we need to come up with a new interface for accessing
> unversioned revprops, and make the current interface do what we
> expect.
Oops!
Let me just say that all those people who said this interface was bad
were right, and I was wrong :-). In good company, but still wrong.
A lesson for the future, maybe:
I think our confusion was that overloading `-r' worked okay for
`propset', since you could never change a property at a specified
revision of a versioned object -- that wouldn't make sense. But then
we carried it over into proplist and propget, where it *would* make
sense to use -r with a versioned object. And since the overload
doesn't work for proplist and propget, we shouldn't have used it for
propset either.
Should we put the current 'propfoo -r' functionality under
'revpropfoo' or `rpropfoo' instead?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn prop* syntax weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
Rafael Garcia-Suarez <ra...@hexaflux.com> writes:
> But I've not found a way to get the versioned property of a file "foo"
> at a specified revision.
Yes, I think this is a hole in our functionality. But then again, you
have no way to cat the text of a specific revision of a file either. ;-)
> This is a problem with the syntax of the prop* commands, but
> I'm not sure how to solve it.
Eric Gillespie and I have talked about this problem at length on irc.
The problem is that our current 'svn propget -r' syntax actually
*seems* like it ought to fetch a property from a particular revision
of a file.... but it does something totally weird instead.
I think we need to come up with a new interface for accessing
unversioned revprops, and make the current interface do what we
expect.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org