You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/11/15 04:09:27 UTC
svn fetch
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
svn checkout == cases 1b and 2
svn update == cases 3 and 4
svn switch == case 1a
The only question is how to handle the case when a URL is provided: where to
put the resulting (new) data. For example:
$ svn fetch http://svn.collab.net/repos/svn
Does that create ./svn/ and put everything there? Or does it put the
contents into my current dir?
"svn switch" would prefer the former interpretation. "svn co" prefers the
latter. If the fetch command is going to fetch new data, then either
approach is valid since the "-d" switch can adjust the behavior.
Fetch could obsolete the checkout, update, and switch commands in one fell
swoop. We would probably choose the "new data behavior" to create a subdir
rather than fetch into "." -- this would mirror "svn checkout" behavior.
"Switching" "." is as easy as fetching the target branch using "-d ." to put
the results into the cwd.
checkout and update (and their aliases) would be aliases of "svn fetch".
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 fetch
Posted by Greg Hudson <gh...@mit.edu>.
On Wed, 14 Nov 2001, Greg Stein wrote:
> Simplify the number of commands the user has to deal with. To me, they are
> much the same, with only slight/minor differences.
I agree. If you look at the code for CVS, "update" and "co" are pretty
much the same command; there are only a few minor differences. (Code
similarity shouldn't really drive the user interface, but sometimes it can
illustrate how similar the semantics of two separate actions are.)
I'm +0 on "svn fetch".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn fetch
Posted by Greg Stein <gs...@lyra.org>.
NOTE: I forgot to clarify in my previous note: svn fetch is/was a though
experiment. At this point, we aren't planning to do it (Karl has some
reservations; Branko, Mike and myself seem to like it). I thought it would
be useful/interesting discussion to have on the list. "Measuring the wind"
is a good thing to do...
On Wed, Nov 14, 2001 at 08:59:33PM -0800, Mo DeJong wrote:
> On Wed, 14 Nov 2001 20:09:27 -0800
> Greg Stein <gs...@lyra.org> wrote:
>...
> > checkout and update (and their aliases) would be aliases of "svn fetch".
>
> Ok, I will bite. Sure, it could be done but why would you want to do this?
Simplify the number of commands the user has to deal with. To me, they are
much the same, with only slight/minor differences.
> I like separating out the "get a new module" concept from the
> "pull in changes from the server" concept.
Those two concepts are legacy concepts. You view establishing a working copy
as an operation and a result in its own right. I see "fetch me the files".
If it needs to build a WC to hold them... fine. That isn't something that
concerns me. That is just the software accomplishing a means to an end. All
that I see is "get me what I ask for. I'm gonna edit them. then I'll send
the changes back."
> Why create a "super command"
> that does it all? If a fetch subcommand was added, would we not want
> to remove the checkout, update, and switch methods? They would just
> be a crutch there to help CVS users that did not understand the power
> of fetch, right?
They would exist solely as a crutch, yes.
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 fetch
Posted by Mo DeJong <su...@bayarea.net>.
On Wed, 14 Nov 2001 20:09:27 -0800
Greg Stein <gs...@lyra.org> 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]
...
> checkout and update (and their aliases) would be aliases of "svn fetch".
Ok, I will bite. Sure, it could be done but why would you want to do this?
I like separating out the "get a new module" concept from the
"pull in changes from the server" concept. Why create a "super command"
that does it all? If a fetch subcommand was added, would we not want
to remove the checkout, update, and switch methods? They would just
be a crutch there to help CVS users that did not understand the power
of fetch, right?
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn fetch
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Thu, Nov 15, 2001 at 08:28:38AM -0500, Kevin Pilch-Bisson wrote:
> 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.
I agree with everything Kevin just said. Having different commands for
different things, rather than one command with many options, seems
more intuitive to me.
-garrett
--
garrett rooney Unix was not designed to stop you from
rooneg@electricjellyfish.net doing stupid things, because that would
http://electricjellyfish.net/ stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn fetch
Posted by Martin Tomes <ma...@southdowners.org>.
Kevin Pilch-Bisson wrote:
> On Wed, Nov 14, 2001 at 08:09:27PM -0800, Greg Stein wrote:
>
>> svn fetch [-r rev] [URL] [wc-path]
>>
> 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.
People who use version control systems think rather differently from
those who write them and maintain repositories! They know the action
they want to perform such as 'get the changes others have made' or 'tag
this file' or 'make my changes available' and they see them as distinct
actions. They also use the system relatively infrequently, some of them
very infrequently, so they will never remember subtle variations on a
single command, they want to type in what they want to do and expect the
version control system to do whatever is needed to acheive that end.
What a user does have to do is understand the basics of the version
control model. A CVS user has to understand tags, branches, merging
etc. An SVN user will have to understand cheap copies, change sets or
whatever you are calling an atomic commit and the way versions are numbered.
What I am asking for is a coherent and easy to grasp model which
describes how the system hangs together and a command set which is easy
for a user to remember given that he/she will use that command set maybe
once a week maximum. I have one user who use CVS about once every six
months - I know that is bad practice but that's real life for you:-(
BTW, I am very grateful for the work you are all putting into SVN, once
it gets nearer to version 1 I will be setting an experimental server up
here. To that end, it would be very helpful if you could put together a
WEB page describing how to get an SVN server up and running on a Linux
server.
Regards,
Martin.
martinto@southdowners.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn fetch
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~