On Sat, Aug 24, 2013 at 2:48 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>
>>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>>
>>>>> I can't, off the top of my head, think of a scenario where it would be
>>>>> harmful to replace an unversioned directory with a versioned instance,
>>>>> leaving any unversioned local files that happen to be there alone.
>>>> Leaving unversioned local files alone in a directory is not the problem.
>>> I think it is the problem we've been discussing. Leaving them means
>>> you have to keep the containing directory, which becomes unversioned
>>> as you switch away from the branch having it,
>> Correct.
>>
>>> and then a conflict when
>>> you switch back.
>> *This* is the problem we're discussing. *This* is what Subversion should be
>> smart enough to avoid. None of the discussion I've read thus far gives me a
>> convincing explanation for why this should not be possible.
>
> 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".
>
> 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.
>
> 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.
>
> And of course, all of the above is not specific to switch -- but also to
> update, when there are no branches involved.
>
> So, yeah, it ain't gonna happen. You /do/ have the option to use
> --force, but there's a reason why that isn't the default.
>
> -- Brane
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. br...@wandisco.com
