On 8/22/13 3:00 PM, Les Mikesell wrote: >> Why can svn not, instead, simply interpret an already existing directory >> > as not a conflict? Certainly if a versioned file would overwrite an >> > unversioned file of the same name then that is a true conflict because >> > the content may differ. A directory has nicely compartmentalized units >> > of content which can be handled in a smarter way. > No, look at your logs of directory history. They aren't just > containers for whatever happens to be there, the history of adds and > deletes are there. It might be possible to make things work where it > would pretend that it created a directory keeping the history from the > repo but ignoring extraneous content, but its not what I'd expect.
Directories also have "content" in the form of properties. The problem is svn doesn't have enough information to make *good* decisions about conflicts between two objects with different histories (regardless of whether the object is a file, directory, or other). Here are some examples: 1.) Two objects added in two different branches have different histories, even if they have the same name and content, causing a tree conflict on merge. 2.) Two objects with the same name where one is versioned (has history) and the other is unversioned (no history) also causes a tree conflict on merge/update/switch/etc. Because a good decision cannot be made, svn punts and requires the user to take action. -- Edwin G. Castro
