On Sat, Aug 24, 2013 at 6:51 AM, Ryan Schmidt
>>> *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.
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 make 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 then 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 loudly 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.
Received on 2013-08-24 17:23:12 CEST