Lost Clones?

[schferk]

Sometimes I would like to export a branch of my tree/database into another UR database. So I discovered - except for my doing something wrong there? - that those items and subitems in that branch can be exported (by copying/cutting and pasting), but without clones: Only the original items are there, and they are always with that curbed indicator arrow that there is / should be a clone, but the clones are gone!

Consider that you do a lot of work within a "file" / "project", so in a subtree of a database, including cloning within that subtree. Then you need this "file" / "project", the subtree, as a separate UR database, in order for sharing with a collegue or with a client, or be it too big or be it that you want to put it into an archive file since the "file" / subtree is not any more worked on but that you want it to archive it for legal reasons or for other reasons, not wanting to delete it, in case you would like to have some possible reference material in it.

(Or even the other way round: You do a special UR database for a given "file" / "project", and when that's finished as such, you want to insert the whole "file" / "project" into a (much bigger) reference database where there are a lot of such (formerly separated) "files" / "projects" put together for reference / archive purposes.)

In any such a case, it would be absolutely necessary to have those "in-file" clones preserved! I understand that clones outside of such an "exported" subtree could not be preserved (or only in a referential way, some indicators of lost clones), but those clones within that subtree should be preserved since UR's cloning feature is without competition, it's perfect in itself, since clones are indicated and can be shuffled around, and if you do changes to sub-items of clones, the clones will preserve those changes, so it's really so good that you heavily rely on this spectacular feature.

But then, any "exporting" of such a subtree into another UR database should not lose all this benefit (since whenever you want to use clones, you then must ask yourself, is there a risk I'll need this subtree in any other UR database at some time in the future, and if yes, you must refrain from using UR's best feature)!

Did I do something wrong so that the clones are not preserved, or is it a functional lack of the program? If so, could you consider implementing this preservation of "in-tree" clones when copying/cutting and pasting such a sub-tree into another UR database?

Please comment on this, it would be extremely important as I see it.

[schferk]

I am very sorry, my considerations certainly apply in general, but not to UR; I got mislead by other program's very poor cloning features, and so I misinterpreted another quirk.

Clones are perfectly exported, and after exporting, they work as supposed, this is outstanding, overwhelming and sensational, my excuses. (I tried with real data where hundreds of items on various levels got me to lose my clones from eyesight, when they were very well preserved.)

The quirk that mislead me, is this: When having cloned an item (and in the same database or after exporting to another one), the search only finds terms in the "original", not in the clone. Perhaps I do something wrong there, again? But now I tried for several times, and for every cloned item, contents are only found in the item from which the clone was created, not in the clone also.

Do I overlook something, then, or can't those terms in cloned items be found as yet? (What I want to say is, the original item appears in the search results list, but not also the clone(s) of this item.)

Again my excuses for pretending the tremendous clone feature doesn't export well, it does, and it's a real pleasure to work with.

[kinook]

Searching works as expected here, including for items and logical links that are copied to another database.

[schferk]

Thank you for your answer and excuse me for my not understanding.

Let's drop the copying / cuttying / pasting; as said before, it works like a dream, and I'm delighted with that.

My problem is, I have, in a given dabase, an item "original". Then I clone it, that item is the "clone" - but of course, the common title of the two items is "commontitle".

In this item commontitle, which exists two times, in two places, there is a search term, lets say "searchterm". I then search for searchterm.

Now, in the search results pane, I get commontitle, ONE TIMES ONLY, and without any indication of its position of the tree. What I want to say is, in the tree there might be selected another, third item which has nothing to do with the original and the clone, but where the focus was when I did the search for searchterm (not being in the third item).

In the text pane, there is displayed the search pane.

Then I click on the (one only) item commontitle in the search results pane, and then, the text pane displays the text of the item commontitle, but it is unclear if this represents the original or the clone. (As said before, any other, formerly selected item is selected in the tree, not one of the items commontitle.)

For the text, this is totally unimportant, of course, since any changes will be automatically synched, from clone to original, and from original to clone(s).

But it makes a difference for the position in the tree, of course, for my "being in the context of the original or being in the context of the clone".

So I double-click on the item commontitle in the search results pane, and then, in the tree, the original (not the clone) is selected, so by double-clicking commontitle, you get to the original's position in the tree, but not to the clone's.

Let me give an example why this "positioning" within the tree, from search results, is important.

Let's assume we have 10,000 items in various subtrees, and we want to make a Getting Things Done or any other task managing system.

Then, a task being somewhere deep in its context has searchterm, and when you want to work on it in context, you double-click, and you're done. If you want to see the item in the "ToDo" context, you cannot go to it this way, but you must go to this "ToDo" context manually, but let's assume this context is on top of your tree, so this is not too much trouble.

But whenever you CATEGORIZE an item under different categories, not a "normal context" and a "ToDo" context, but real, different, systematic categories, you are in trouble since you cannot go to the item but in its original context, not in the (equally important and equally deeply hidden) context to which some time in the past you had cloned it.

As an example, let's consider 1,000 items in chronological order, within 10 ranges of time, let's say 50 items in range 1, 150 items in range 2, and so on, let's say historic ranges of centuries or of 10 years, 10 times 10 years of a century, and the occurrings in those ranges of 10 years.

All those items / occurrings / historical facts must be cloned to several systematic categories, let's say Power, People, Science, whatever, let's say 20 or more categories, and each historical fact is cloned into at least one of those.

This "has it been categorized at least once" problem is gladly resolved by the fact that every entry must have the curbed arrow indicating its cloning status; if ever an item does not have that arrow, categorizing has to be done yet (so you check by sight).

But now, the problems arise:

You don't want to have a real mess in the search results, so since UR always shows the original, not any clone by double-click in the search results (and this even when the clone, in the tree, is above the original), you MUST enter every item first in the chronological category, in order to have those double-clicks aim at this head category "chronological"; if ever you are in any systematic category, and you want to create a new item, you must first go manually into the concerned chronological category (let's say "1830-1839"), in order to create the original there, and then only you'll go back to the corresponding systematic category, to do the clone there, since if you worked in a natural way, your original would be in the systematical category, when the clone would be in your chronological category, and this way, any double-click on commontitle would once put you in the chronology, once in the systematic categories, depending on where you created your original.

This is most akward, I think; a solution would be to not differenciate original and clone anymore, internally, but that double-click on a commontitle in the search results pane would put you to the FIRST occurence of any original or clone in the tree.

This way, if you are doing heavy work on your cloned things, and if you normally want to be put into the chronology of your subjects, by searching for search terms, you could put your chronology, in the database, BEFORE the categories; or the other way round, when you want your searching putting you into the categories, you would first put them before your chronology; the same considerations would apply to any other categorization: If you want your search to lead you to categories "A", you would put those above categories "B", and vice versa; the same would apply to multiple "level a" categories, A, B, C, D...: Their order in the tree would then decide upon your double-click showing the occurrence of your search result, be it the original or one of its multiple clones.

Or then, by option perhaps, the search results pane would display ALL occurrences of commontitle, original, clone, etc. - in tree order. This way, looking for hits in category A, you would know that the first occurrence must be double-clicked, and for hits in category C, you would double-click the third occurrence of commontitle in the search results, and so on.

The above problem is widened by the fact that the double-click on the (only) commontitle item in the search results pane SHIFTS this pane to a "children" pane, so there is not a solution given by perhaps double-clicking a second time on commontitle in order for the tree selecting the second occurence / the clone of commontitle.

As it is, hits in clones are simply not found, since the tree invariably displays the original, not the clone. I hope I could explain why this should be amended?

I think any solution that would give the first occurrence in the tree, instead of the "original" occurrence, would be rather simple to implement and a big step ahead, since users could work as they feel, in creating the original or the clone first (for users, it would not make any difference, that is, even if on a technical level, it would be the other way round), and the positioning in the tree of their big categories would then decide on where searchterm searches would put the user in the tree.

[kinook]

There is no "original" link for a logically linked item -- each link to an item is equal to all others.

If you click on a search result, the Item Parents pane will show all parents where the item is logically linked, and double-clicking one will take you to that parent item.

To show all logical links for an item in search results, show one or more of these attributes (View | Choose Columns):

Lineage
Parent Title
Tree Order
Indent Level