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

Re: svn fetch

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-11-15 06:05:13 CET

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 <gstein@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
Received on Sat Oct 21 14:36:48 2006

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.