Understanding How Segments Merge
Every time new URL references are added to a fusker collection by any automated process fusker trees
are merged. This includes anytime the
button is used, any time the URL Capture Bar is used,
and anytime you choose Merge from the File Operations menu.
Merging starts at the top of the fusker tree with the Collection segment and works its way down each branch of the tree from top to bottom in order pairing segments which fall at the same level on the same branch of the tree.
The merger process consists of 3 steps taken at each segment level:
- Match up the level of "Roll Up"
- Determine if segment information can be merged
- Absorb child segments
Matching The Roll Up
Before we can determine if two segments can merge, we must first make sure they contain information about a similar portion of the fusker tree. To do this we need to match the number of directory branches contained in each segment. It may be necessary to Split or Roll Up in order to make an accurate comparison. This is done by counting the number of directory markers (i.e. "/") present in both segments then causing the new segment to either split or roll up the correct number of times to match the number of "/" markers.
The structure of the fusker tree being merged to the existing fusker tree is changed by this process. which makes the merger process Directional. If you merge two fusker collection files the result may be different based on which file is loaded first and which file is merged.
An example of the directionality of the merger process can be seen in how the following trees would merge.
| Generic Examples of matching the Roll Up level | ||
|---|---|---|
| In our first example our loaded tree does not have any split directories. The tree we wish to merge into our current tree has split the directory 3D_Model02 is split between 3D_ and Model02. Matching the Roll Up of the second tree to the first tree will roll up the split directory to create a directory segment 3D_Model02. Once this is done it is determined the directories do not match and a new branch of the tree is created. | ||
| Existing Tree | Merging Three | Resulting Tree |
 |
 |
 |
| If we reverse the order of the two collection files and merge the tree with no split directory into the tree which does have a split directory, we see a different result. In this case the directory 3D_Model01 is split in order to match the split directory 3D_. The remaining portion of the directory (Model01) doesn't match an existing branch of the split direcotry so is absorbed as a new branch below the split directory. | ||
| Existing Tree | Merging Three | Resulting Tree |
|
|
 |
This may seem quite complex, but in most cases you will find the results are actually quite intuitive. It may still be possible to create tree branches where the merger can't reconcile the roll up levels - in which case the two tree structures may both exist in some form within the merged tree even if a human could have made a better merger of the trees. In such cases you can manually manipulate the trees to have the structure you wish.
Determining A Merger
While the general merge process is similar for each segment type, they all behave slightly differently and will combine with only segments of a similar type. If the information in the merging segment can not be combined with the existing segment the segment is passed back up to the parent for comparison with other branches or absorption. The following table describes which segment types will combine.
| Segment Type | Can Merge With | Condition | Result |
|---|---|---|---|
| Collection | Collection | Always | You choose which set of data to keep, the merging tree branches are absorbed |
| Path | Paths | Only if both text and protocol match | Exact matches combine the lower branches |
| Directory | Directories | One segment must contain completely and exactly the other segment's information. |
The most complete set of information is retained and the child segments of the merging tree are
absorbed. If one or both of the segments are fusked, the larger fusk is maintained The directory or split directory which matches the most characters of the merging segment will be chosen as the "best" match. This allows identical matching regardless of the order of the segments in the current fusker collection. |
| Split Directory |
Split Dir Directories Files |
The information in the existing segment must be completely contained in the merging segment. There may also be additional information in the merging segment which can be used to form a child segment. |
The most complete set of information is retained. If one or both segments are fusked, the larger
fusk is retained. Any additional information contained in the merging segment will be used to
form a child segment for absorption. The directory or split directory which matches the most characters of the merging segment will be chosen as the "best" match. This allows identical matching regardless of the order of the segments in the current fusker collection. |
| File | Files | File Segments combine based on the {Auto combine individual files into fusked files} User Configuration. | If this configuration is enabled, individual file segments will be combined into an optimized fusked file segment. Otherwise individual files will be listed as branches under the same directory or split directory segment. |
When file segments are merged because the {Auto combine individual files into fusked files} configuration is enabled, the entire text (both filename and extension) of each file referenced by both segments is first formed into a single list fusk. During the formation of the list fusk, duplicates are removed and what remains is a list of each file at the destination path referenced by both of the original file segments. The Optimization Process is then applied to the newly created fusked segment.
Absorbing Child Branches
The process of absorbing the child branches of the merging segment is an iterative and recursive process. This means we will ask each of our child branches to merge with each of the child branches of the merging segment. The first or our branches which decides it can and will combine information with the merging segment's child will then ask each of our grandchild segments if they will merge with each of the segments grandchild branches and so on until there are no more child branches.
Each of our child branches will be given the opportunity to combine with a child branch of the merging segment if we ourselves have determined we can combine information with the merging segment. Each child branch is given the opportunity in the order they are listed from our top branch to the last of our branches. If none of our branches can combine with the merging segment's branch we will add that branch to the end of our list of branches (including the entire branch of child segments).
The first child branch which can combine with the merging segment's branch will in turn ask each of it's own child branches about combining with each of the merging segment's grandchild branches and so on till there are no more child branches to be considered.
