Thanks Travis. I thought this was a binary patch, not a source code patch. Now I realize that since subversion gets compiled into a variety of executables a binary patch can not be done. I do not wish to compile subversion. I have found that --force works and I only need it if switching to a branch that has any new libraries. Switching away from that type of branch works fine.
-----Original Message----- From: Travis Brown [mailto:trav...@travisbrown.ca] Sent: Monday, August 26, 2013 2:58 PM To: John Maher Cc: Subversion Subject: Re: Switching On Mon, Aug 26, 2013 at 01:31:49PM +0000, John Maher claimed: >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. > It's a patch you need to apply to the Subversion source code before building it. On a Unix-like system the following steps are what I do: daredevil:~/temp $ tar -jxf subversion-1.8.1.tar.bz2 daredevil:~/temp $ cd subversion-1.8.1 daredevil:#emp/subversion-1.8.1 $ patch -p1 < ../local_unversioned_dir-incoming_add_dir.patch patching file subversion/libsvn_wc/update_editor.c Hunk #1 succeeded at 2249 (offset -1 lines). daredevil:#emp/subversion-1.8.1 $ You would then go ahead and build Subversion as normal for whatever platform(s) you are on. Unfortunately I cannot provide any guidance on how to accomplish this with a packaging system such as RPM or on Windows. If you don't have existing infrastructure and procedures to install and update software installed from source then this patch may be a greater maintenance headache than it's worth. -- Travis > >-----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 >
