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!)
If you have local mods on a file, and you run either 'svn up' or 'svn
switch', and the tree you're receiving has that file missing, then you
get a standard conflict: you changed a file, someone else deleted it.
Big deal. At the moment, when such a conflict happens, your file
becomes unversioned.
(Although maybe we should file a bug here: the output never indicates
any conflict at all!)
Anyway, the point is that two developers didn't communicate well,
regardless of whether the conflicts happened between two revisions of
the same location, or between two different locations. 'svn switch'
shouldn't go behaving differently than 'svn up' just because most
people typically use it to update to a new branch. That would be as
silly as the filesystem treating a directory differently because it
lives in a '/branches' area. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 17 19:50:04 2002