Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of lesmikesell@gmail.com
 designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9DEB2347-7103-49A2-AC8C-51C8223C3069@ryandesign.com>
References: <910250F21FAA2A4E8F72DD21EA7807660906148C@VMJudi.corp.rotair.com>
	<910250F21FAA2A4E8F72DD21EA7807660906CE46@VMJudi.corp.rotair.com>
	<1803569830.20130822182126@am-soft.de>
	<910250F21FAA2A4E8F72DD21EA7807660906CE8C@VMJudi.corp.rotair.com>
	<CAB84uBUkwB=Htu+0bkU12Jp6HCy_iXxiyePxsH98_b=4nKrmcg@mail.gmail.com>
	<910250F21FAA2A4E8F72DD21EA7807660906CF0C@VMJudi.corp.rotair.com>
	<1B05D8F50421E24799AE93B03CC284BE01CB235198@CRPMBX01.corp.cbeyond.net>
	<910250F21FAA2A4E8F72DD21EA7807660906CF5A@VMJudi.corp.rotair.com>
	<5216589C.1030308@gmx.us>
	<910250F21FAA2A4E8F72DD21EA7807660906CFD5@VMJudi.corp.rotair.com>
	<521665CF.7050807@gmx.us>
	<81E45292CF3BC5478E88DF55E216AD2F03B46E5E@FLONIDANPOST.flonidan.net>
	<52178B18.9050007@gmx.us>
	<CAOAgVpzE3cGpyF5QJ0L2FyKiRHTgyTP2z-RCGrDpm0-wAt2D6Q@mail.gmail.com>
	<5217A562.3020202@gmx.us>
	<54C87FD8-9CBD-41A3-9D6B-F7C1C787BB60@ryandesign.com>
	<5218656B.6020302@wandisco.com>
	<9DEB2347-7103-49A2-AC8C-51C8223C3069@ryandesign.com>
Date: Sat, 24 Aug 2013 10:22:41 -0500
Message-ID: 
 <CAOAgVpzO2+YG1=5fe4Atc-28jLs8eRDtVEyrjcuuhYtOJJjPFA@mail.gmail.com>
Subject: Re: Switching
From: Les Mikesell <lesmikesell@gmail.com>
To: Ryan Schmidt <subversion-2012c@ryandesign.com>
Cc: =?UTF-8?Q?Branko_=C4=8Cibej?= <brane@wandisco.com>,
	Subversion <users@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 24, 2013 at 6:51 AM, Ryan Schmidt
<subversion-2012c@ryandesign.com> wrote:
>
>>> *This* is the problem we're discussing. *This* is what Subversion shoul=
d 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.

I'm not sure anyone proposed silently assuming anything.  I'd suggest
adding a way to tell it to overwrite unversioned directories and files
with identical contents without also telling it to overwrite files
with differing content.

>> 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".

Don't forget that it was subversion, not the user, that created the
directory and abandoned it in the first place.   Yes, some of the
other tools the user uses may be equally dumb about leaving cruft
behind and confusing svn, but the user may not know the internals of
all the tools.

> If, as you said below, this shouldn't happen generally, then one way to m=
ake Subversion smart enough would be to have it remember when it converted =
a directory from versioned to unversioned due to a switch, so that it can t=
hen seamlessly transform it back if the user switches back.
>
>
>> 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.
>
> Certainly if there are *file* conflicts then Subversion should complain l=
oudly and not do anything automatically, however that was not the scenario =
the person who opened this thread posed.

I'd propose that file conflicts aren't really conflicts if the
contents are identical.   And that there should be a way to tell
subversion to go ahead and force overwrites of directories and
identical file contents without, at the same time, telling it to
clobber files with differing data.

--=20
   Les Mikesell
     lesmikesell@gmail.com