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

Re: svn switch to move between servers

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-09-17 20:04:33 CEST

On Tue, Sep 17, 2002 at 12:48:17PM -0500, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > 'svn switch' is EXACTLY the same as 'svn update'. Identical code
> > > paths. They both compare two urls, and apply the differences to your
> > > working copy.
> > >
> > > Just like 'svn up', 'svn switch' will merge changes into your local
> > > mods, creating conflict markers if necessary.
> >
> > Hunh. I thought we were going to disallow switching with local mods. If
> > somebody changes a file, then it doesn't necessarily apply to that same file
> > on a different branch.
> That's true. So people shouldn't use 'svn switch' in a stupid way.
> It's no more or less dangerous than 'svn update'. If somebody has
> made a whole bunch of conflicting changes, and you run 'svn up', your
> local mods may not apply anymore. That's what conflicts are for. We
> never lose local mods, as a rule.
> > At a minimum, if local mods are present on a file which is not present in
> > the new location, then the switch should bail rather than tossing the
> > change.
> To me, it seems silly to define two different types of conflicts --
> 'svn up' conflicts, which are fine, vs. 'svn switch' conflicts, which
> cause general bail out? What's the point? (Remember that you're the
> one, Greg, who wanted update, switch, and checkout to all be ONE
> command!)

Yah. True true...

Musta brain-farted or something.

> (Although maybe we should file a bug here: the output never indicates
> any conflict at all!)

Yah. That is bad. You gonna file an issue?


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 Tue Sep 17 20:04:47 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.