Hello 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.
-----Original Message----- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Saturday, August 24, 2013 5:58 PM To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; d...@subversion.apache.org; John Maher Subject: 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
