On Thu, Apr 26, 2007 at 11:13:48PM +0200, Christian Boltz wrote:
I'd like to add another feature request: if PROJECT and PACKAGE are not given, the values should be determinated from the current directory.
Example / usecase:
I'm in the directory where I checked out package foo from project bar - which is known to osc when doing "osc up" or "osc commit". Now I want to edit the metadata of this package and call "osc editmeta". The result is "missing argument". Instead, I have to type "osc editmeta bar foo"
Expected behaviour: take the project and package name from the current directory (as already done with "up" and "commit"). This would save lots of needless typing.
I have been thinking about this several times, but didn't come to a conclusion yet. It wouldn't fit all subcommands equally well. A disadvantage would be, that for some subcommands, which take more than those two arguments, like osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] it will become (at the least) confusing, if osc has to guess what to do. Of course, the current inconsitencies of subcommand implementation need be fixed. For example, osc results [PACDIR] which requires a checked out package, versus osc rebuildpac PROJECT [PACKAGE [PLATFORM [ARCH]]] which works purely remote. I think what I fancy most is to put server-only subcommands into a separate command, named e.g. osc-remote. That command would principally require a project and package argument, and behave identically otherwise. I think this would be more convenient than adding commandline switches that modify the behaviour. Would that be reasonable? svn makes this distinction based on whether URLs or local paths are given as arguments. I'm not sure we want to do the same, I find to <prj> <package> arguments easier to use than a full url. Peter -- Allen Gewalten zum Trutz sich erhalten. SUSE LINUX Products GmbH Research & Development