Re: svn switch to an incorrect branch deletes modified local files

On Wed, Apr 23, 2008 at 06:07:29PM -0700, Aaron Eppolito wrote:
> Note that the scenario involves a tree conflict. See use case 2:
> http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases.txt
> Just replace "update" with "switch" and "move" with "deletion"
> in that description, and you get the situation we're talking about.
>
> Aaron, the corresponding issue in the tracker is:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2282
>
> Yep, given the substitution, that seems right. ;)
> I suppose anything that warns you *before* mangling your WC would be
> infinitely preferred. As I replied to David, a warning ahead of time
> (that would require a --force) would be great.

Well, to tell you what would happen when you do a switch,
we need to do (or simulate, see below) the switch first.
We can't magically predict what will happen when you switch
some arbitrary working copy to some arbitrary directory in
the repository without doing so and looking at the result.

> Donald's comments from
> 2505 echo my sentiment too:
> ------- Additional comments from Donald H Locker Fri Jul 13 04:53:56 -0700
> 2007 -------
>
> This would seem to me to be a good candidate for a --dry-run type of behaviour,
> or a verification step before actually attempting to execute the switch.
>
> An error message of "can't switch - [files/directories list here] would be lost
> or damaged" would be very useful.

You can (and probably should) run switch with --dry-run first.
With tree-conflict detection in place (i.e. not with 1.5, nor
trunk, but our experimental tree-conflicts branch), this will
notify you about conflicts, i.e. you'll see directories flagged
as 'C'. (*lightbulb* Hmmm.... we might actually want to print a
summary of all potential conflicts of any kind after any --dry-run
operation... Cc'ing Julian Foad. Julian, do think this would be
a good idea?)

I suggest that in your work flow, you make it a habit to use
--dry-run for things that you know may cause trouble (such as
whenever you accidentally supply the wrong switch target ;)

Making --dry-run mandatory would be needed to get the warnings
you want by default, but if we did that, people would start
complaining about performance :(

Note that nobody is stopping you from using wrapper scripts
around svn in your software development process that enforce
certain behaviour though.

> As it is, I have to look at all the bits I
> know have changed and figure out how to set them aside/protect them, do the
> switch and restore them. Not so bad with ignored or unversioned artifacts, but
> added and renamed bits are a pain.
>

Well, yes, you will have to look after "all the bits" (we call them
"tree conflict victims" in our design). But you will have to do that
either way. Even if svn said:

  "I can't switch, because this threatens <long list of files and dirs>.
   Use --force to switch anyway."

...and you used switch --force, you may still have tons of files
dropping out of version control, so you may have to re-add them.
And worse, you may potentially forget about some of them, but
commit anyway, and break your project's tree, and have half the
development team knock on your office door to ask wtf you just did
to the tree and why.

> In general, warning on a conflict after the fact in my particular case
> wouldn't be really helpful. I knew I had seriously messed up when I saw a
> hundred 'D's go by followed by the project starting to check out!

Yes, your particular case would trigger tree-conflict detection,
but isn't the intended use case for it. You supplied a wrong
argument to switch, that is the core of your problem. And svn should
be able to cope with that. But how do you expect svn to be able
to tell you which directory in the repository you want to switch
to? This may be a weakness in our branching model, but it's arguably
a trade-off, really -- svn as a tool gives you lots of flexibility,
but at the price of potentially shooting yourself in the foot
if the tool isn't used right. It's bit like the C programming
language in this way :)

Note that file1.cpp may drop out of version control even if you do
an operation that looks sane at first sight. Usually, you don't
have lot's of 'D's to warn you when you run into this kind of problem.
You saw all the 'D's, got alerted, and *then* noticed that file1.cpp
was suddenly "gone" (unversioned). You sort of hit a tree conflict
by accident, and noticed it only because something else weird was going on.

But such a tree conflict may happen any time someone deletes a file
and you run update on top of that file, which you've locally modified.
Hardly uncommon...

By flagging such things as conflicts, we're making sure that you
*can't* break your project's tree as a result of such an event
and similar events. You simply can't commit any of the affected
items until you've made a concious decision about what to do about
each of them.

Unless you chose to ignore the problem and ran "svn resolved"
on all items without thinking about the consequences, of course.
But that would be your own problem, and *you* would have to explain
this to your co-workers, not us :)

Think about it in terms of a conflict. Just as with text conflicts, we
cannot tell you in advance whether they will happen. The conflict in
your case is not in file content, but in tree structure. Running the
switch on your working copy essentially tells svn "modify this file,
no... wait, delete it at the same time, er, ...no, modify it, no, wait,
delete it..., etc., etc." These are conflicting operations.
Subversion cannot figure out automatically what you want it to do.

It's a similar problem to when you tell svn that line 5 in a file should
be "foo" and line 5 in the same file should be "bar" at the same time
(text conflict).

Does it make sense now?

-- 
Stefan Sperling <stsp_at_elego.de>                    Software Monkey
 
German law requires the following banner :(
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                               CEO: Olaf Wagner
 
Store password unencrypted (yes/no)? No