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
Received on 2013-08-23 00:30:55 CEST