Re: Switching

On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we
>don't know what the contents of the incoming directory will be nor
>what the user may eventually want to do to resolve the problem.
>Making the unversioned directory versioned is just one possible
>options among several.
>
>See Branko's post: http://svn.haxx.se/users/archive-2013-08/0478.shtml

I read that and I still wrote and posted the patch because the arguments
there bear no relation to what _this_ patch does. That post does a fine
job describing a few challenges for what a more complete system would
do. This patch just makes the ratchet not cut the user's knuckles when
they reverse direction, it isn't the fully automated manufacturing plant
most of this thread seem to be talking about.

John, before I go onto to exhaustively say my final piece on this matter,
you have my patch[0] which I believe makes your use case work. If you
have the resources to run an otherwise standard SVN binary with this
patch applied I would consider doing it.

Now I'll address Branko's points directly in a tedious fashion.

>> You're assuming it is correct, in all cases, to silently make a
>> directory versioned because the incoming directory happens to have the
>> same name. It is not. It may be marginally correct in your case,
>> however, Subversion has no way of knowing that the unversioned directory
>> it sees is in any way related to whatever is on the switched branch. It
>> needs user input; it cannot magically become "smart enough".

This thinking is much higher level and trying to do much more than this
patch. This patch doesn't attempt to deal with trying to merge the
existing unversioned file hierarchy and the incoming version object
hierarchy. It merely avoids unnecessary tree conflicts on directories
in _one_ specific case. The general problem is hard, but this is not the
general problem.

>> For example, consider a typical Java module which has "build.xml" file
>> and two directories, "src" and "test". You add such a module called "A"
>> on the branch. Someone else creates a completely different and unrelated
>> module in their working copy, incidentally also calling it "A". Then
>> they switch to the branch. What happens?
>>
>> You're proposing that Subversion would say, "Oh, this unversioned thing
>> I have here is also called "A", I'm going to assume its the same as the
>> incoming directory, let's make it so." And in the next step: "Oh, I have
>> an unversioned file called build.xml, I'll just assume it's the same as
>> the incoming and merge changes in...." boom, instant merge conflict.

This goes further than this patch attempts. This patch only says "I see
you have an existing directory called A. I won't make you move/delete
it, instead I'll just continue on filling in this hierarchy as if I
created this directory." Significantly, this patch doesn't change
anything about how _files_ within this hierarchy are dealt with. If you
have an unversioned _file_ within the directory with the same name as in
incoming versioned object then you still get a tree conflict as you
would in a similar situation without an incoming directory.

[As an aside a merge conflict is superior in every case to a tree
conflict. It would be useful if some other patch changed this case from
a tree conflict to a merge conflict where svn didn't try to merge
anything, but only gives you the Theirs, Mine, Edit (and equivalent)
options. But that's a separate discussion.]

>> It actually gets worse, because following your proposal, Subversion will
>> happily recurse in the same way into src and test -- the final result
>> being an unholy mess that you're going to have a fine time untangling,
>> not to mention that you just messed up the poor user's unversioned local
>> changes.

As noted above this patch doesn't modify _anything_ local in any way
which is not obviously reversible. The existing directory has no
permissions or properties changed. No existing files are modified at
all. The directory now contains files it didn't originally, but svn will
tell you which files were originally there since they are either
unversioned or in the conflict state.

>> And of course, all of the above is not specific to switch -- but also to
>> update, when there are no branches involved.

Of course the same issue where svn refuses to do the right thing exists
during update. I'm pretty sure, but did not test, that my patch also
covers this situation. What are the sensible user actions upon a local
unversioned-incoming add tree conflict upon a _directory_ with no files
within it?

Delete it? Rename it to delete it later?

What about a _directory_ with unversioned files within it? I suppose the
user could delete the directory and all the files within it, or rename
it and then move the files back later. The consensus of this list seems
to be give up on switch as a uselessly broken feature. It's not like
anybody would want to save all those build products or local
configuration files to avoid multi-hour rebuilds when changing branches
or anything.

I'd be interested to hear of a single situation where _this_patch_, not
some theoretical tree conflict resolving AI which bears no relation to
this patch, does the wrong thing and the wrong thing is _worse_ than the
existing functionality.

-- 
Travis
[0] http://svn.haxx.se/users/archive-2013-08/0485.shtml