[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Switching

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 24 Aug 2013 09:48:59 +0200

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. brane_at_wandisco.com
Received on 2013-08-24 09:49:37 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.