RE: Switching

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:travisb_at_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:travisb_at_travisbrown.ca]
>Sent: Saturday, August 24, 2013 5:58 PM
>To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion; 
>dev_at_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
>