[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 an incorrect branch deletes modified local files

From: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 23 Apr 2008 17:02:09 -0700

On Wed, Apr 23, 2008 at 4:51 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> Aaron Eppolito <aarone_at_apple.com> writes:
> > I've posed this warning on Apple's internal svn mailing list and a few folks
> > have suggested I file it as a bug. It seems policy is to bring it up in this
> > forum first. I've searched through the bugs and the ~950 matches on "switch"
> > on this list and haven't heard mention of the problem.
> >
> > In very short summary, if you inadvertently switch a subdirectory to a branch/
> > tag/head of the root level, it will DELETE all files in the subdirectory,
> > INCLUDING locally modified files.
> >
> > A concrete example:
> >
> > [myproject/Subdirectory/Files]% svn stat
> > M file1.cpp
> >
> > [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk
> > D file1.cpp
> > D file2.cpp
> > D file3.h
> > A //// the entire trunk's directory structure...
> Yes, "D file1.cpp" will fly by in the output, but 'file1.cpp' is still
> there on disk -- it is preserved (as a now-unversioned file) precisely
> because it was in a modified state when still versioned.
> > I understand that what I should have done was this:
> > [myproject/Subdirectory/Files]% svn switch https://svnserver/myproject/trunk/
> > Subdirectory/Files
> >
> > That said, svn has enough information to know that switching to a new working
> > copy rooted in the current directory is not the right thing. It should have
> > warned, saying something like "This directory does not correspond to https://
> > svnserver/myproject/trunk".
> No, switching to a new working copy rooted in the current directory is
> fine -- people do it all the time, and Subversion has no way to know
> whether it's right or wrong for your given situation.

Eh, I deny that it's "fine"... the current working copy code has a
high probability of breaking your wc if you do a weird switch (issue
#2505). This broader issue probably is easier to fix in a wc rewrite
which constructs a full metadata tree before actually trying to muck
with user files.

Of course, it still shouldn't mess with modified files, and I believe
you that it doesn't.


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-24 02:02:22 CEST

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.