If the same object can be on multiple locations in the same tree, then you don’t have a hierarchy. At the very least, you have multiple hierarchies. Or perhaps you have some many-to-many relationships.
In any case, I think you need to think more about your data model. You probably need to break down the hierarchical scheme into several orthogonal dimensions. You might be thinking that campaigns are nested in theatres of combat, but it might make more sense for geographic location and events to be separate hierarchies –especially when you have an event that spans more than one theatre.
Some dimensions may be simple categorical, others ordinal (rank), others hierarchical (a series of nested categories), and others can lists (multiple separate category selections, where each selection may itself be hierarchical). Each imply different a user interface design, and, furthermore, you’ll probably have a different design for entering the dimension values for an object than for retrieving an object based on its dimension values.
For example, you can have one dimension be the importance of the document (e.g., on a 5-point ordinal scale), and another being a list of relevant events. For dimension-value entry, this implies the UI shows the document details necessary for determining the dimension values, and has radio buttons for setting the importance. The user can select from a list or tree of all events one or more events of relevance which appear in a separate Relevant Events list (like entering email address to the To line).
Or maybe you want to rate the document’s importance for each relevant event. That implies that the Relevant Events list is a table with radio buttons or drop downs to enter the importance for each event.
In summary you may want to think more along the lines of a relational database, rather trying to force-fit the data into a single hierarchy. Studying the UIs for various databases can give you ideas on how to handle your case.