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

Re: rapidsvn feedback

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-31 22:18:14 CEST

Josef Wolf <jw@raven.inka.de> writes:

> So you "svn update" to go back/forth along a branch and "svn switch"
> to jump from one branch to another? Seems that I am beginning to
> understand :) Looks good. It was always hard to explain new co-workers
> the overload of the "cvs update" and its -A switch =8). What happens
> when you give "svn update" a wrong URL (one directory too deep or some
> such?)

'svn update' doesn't take a URL argument, only 'svn switch'.

But yes: they are both the same code under the hood. The only
difference is that 'svn update' assumes that the URL isn't changing;
it keeps the working copy on the same URL, just changes the revision.

> Hmmm, I find it very confusing to speak about URLs when you really
> mean branches. Maybe I am too biased to cvs philosophy, but I think
> most SCM systems have a concept which is similar to cvs-branches.

You just haven't been indoctrinated yet. :-) Perforce has the same
idea: all tags and branches are just ordinary directories.

> But isn't "update" just a special case of "switch"? Can't you always
> substitute an "update" through a "switch"? And then: should the user
> really care which command is used internally? I think that on the
> User-Interface it would make very much sense to speak about
> "branches", "tags" and "revisions" and hide the "URLs" and
> "directories" that are used internally. This is just because most
> people are already used to "branches" and "tags".
> Any opinions to such a proposal?

Yes. We want all users to understand that branches and tags are
ordinary directories. We don't want to "cover up" this design
aspect. We made this decision a long time ago.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 31 22:19:54 2002

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.