From: John Maher <JohnM_at_rotair.com>
Date: Mon, 26 Aug 2013 13:31:49 +0000
Can you provide me with a link as to how to apply this patch? When I search for applying a subversion patch all I get is stuff involving svn diff. I think the patch may be safer than using --force with switch for which all the ramifications I do not even know.
On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
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 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
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"
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
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
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  http://svn.haxx.se/users/archive-2013-08/0485.shtmlReceived on 2013-08-26 15:37:00 CEST
This is an archived mail posted to the Subversion Dev mailing list.