[not cross-posting to users@ as this is a dev@ topic] On 24.08.2013 23:57, Travis Brown wrote: > 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.
Since your patch does not affect the behaviour with files, you'll get tree conflicts on any identically-named files, not merge conflicts (see my build.xml example). I frankly fail to see how that's better than having one tree conflict on the directory. Even assuming the ideal situation where the intersection of the contents of the (unversioned) local tree and the incoming tree is empty (i.e., the trees are completely different except for being rooted on a directory with the same name), so you don't get any tree conflicts on files, the result will be a union of those contents. Now for the particular use case that started this whole discussion, where the unversioned contents consist entirely of generated files, that's not a problem (barring strange effects on build tools). But for every other case it is, so you can hardly claim that your patch would have no adverse consequences, especially as the assumption is that Subversion would merge the trees silently, without even warning the user. You could end up with two distinct and perhaps conflicting modules merged into one, with the extra bonus that your build might not even fail. Seems like a good way for introducing bugs into the code base. :) (Not to mention that from the point of view of CM processes and repeatable builds, this is a nightmare). -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
