On Wed, Nov 14, 2001 at 08:09:27PM -0800, Greg Stein wrote:
> One of the ideas that I had in the meeting last Friday was to rationalize
> some of our subcommands into a single concept. There may have been a name or
> two beforehand, but it ended up as "svn fetch".
> The basic concept is simple: fetch me some data.
> The form of the command is also simple:
> svn fetch [-r rev] [URL] [wc-path]
> The combinations are:
> 1) svn fetch [-r rev] URL
> a) "." is a working copy: fetch any necessary data and switch the working
> copy to correspond to URL (of a specific revision)
> b) "." is not a working copy: fetch the contents of URL (of a specific
> revision) into "."
> 2) svn fetch [-r rev] URL wc-path
> fetch data (of a specific revision) into the specified wc-path
> 3) svn fetch wc-path
> fetches updated data for wc-path from its corresponding URL
> 4) svn fetch
> same as (2) with "." as default wc-path
This does seem reasonable, but I am reminded of something I once read
about operator overloading in C++. People use it for things that are
_ALMOST_ the same as what the operator is usually used for. Thus people
have to check the docs for the operator anyway, when a well named
function may have been more appropriate.
This seems similar to me: is it going to be easier for people to remember
the semantics of what will happen with different arguments to svn fetch, or
to remember what checkout, update, and switch do? I don't know, but
thought I would see if anyone else does.
Note that this doesn't mean that I am against simplifying, and combining
the code paths for these functions, just that I am unsure about how to
present the UI for them.
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Sat Oct 21 14:36:48 2006
- application/pgp-signature attachment: stored