Examples

Branching a Folder

Branching a folder maintains shares between files and subfolders that are self-contained within the branch, but breaks shares to any link outside the new branch.

For example: If $/foo/a.txt, $/foo/bar/a.txt and $/xyz/a.txt are all shared, and $/foo is branched to $/fooBranch, then $/fooBranch/a.txt and $/fooBranch/bar/a.txt are shared in the new branch. They are not shared with the three original links for a.txt. If in the example the $/foo/a.txt was not part of the share in the trunk, then the file would not be shared at all in the branch because there would be no other links within the branch to share with. This works the same way for folder shares that would be self-contained within the new branch. Deleted links should be counted as actual links when determining whether an item should be shared in the branch.

Folder Shares

A Folder Share keeps two or more folders completely in-sync with each other so that any change to the folder or its contents (adds, deletes, check ins, renames, etc) is automatically updated in all folders that are part of the share. This has the effect of introducing a secondary share on all the files and subfolders within the shared folder to their counterparts in the other links of the shared folder.

For example, if $/foo/bar is shared with $/xyx/bar, you can share $/foo/bar/a.txt to $/a.txt, and $/a.txt automatically becomes shared with $/xyz/bar/a.txt too. A file share icon now appears on all three links. Breaking the share at either $/foo/bar/a.txt or $/xyz/bar/a.txt will break it from both places (due to the folder share), and $/a.txt will become unshared (although if a fourth link had been created, $/a.txt and the fourth link would remain shared with each other).

Primary and Secondary Shares

The example below should help understand the difference between primary and secondary shares:

Assume we start out with the following, one shared file (a.txt) with three links.

$/bar/foo/

$/bar/foo/a.txt (Shared)

$/bar/foo/b.txt

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz

Now, we apply a folder share at $/bar/foo with $/xyz:

$/bar/foo/ (Shared)

$/bar/foo/a.txt (Shared)

$/bar/foo/b.txt

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz/foo/ (Shared)

$/xyz/foo/a.txt (Shared)

$/xyz/foo/b.txt

Now $/bar/foo is shared with $/xyz/foo, so all files within it a secondarily shared. In addition, since a.txt already had a primary share, it inherits the primary share and has a primary share the other a.txt files as well.

Now if we add c.txt and delete b.txt from $/bar/foo, $/xyz/foo gets updated with those changes as well:

$/bar/foo/ (Shared)

$/bar/foo/a.txt (Shared)

$/bar/foo/b.txt (deleted)

$/bar/foo/c.txt

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz/foo/ (Shared)

$/xyz/foo/a.txt (Shared)

$/xyz/foo/b.txt (deleted)

$/xyz/foo/c.txt

Next, if we pin a.txt, and c.txt in $/bar/foo, then a.txt and c.txt both get pinned in $/xyz/foo as well at the same version. Note that $/a.txt and $/proj/a.txt do not get pinned too, because a pin operation only applies to a single primary link. However, they apply to all links in a secondary share.

$/bar/foo/ (Shared)

$/bar/foo/a.txt (Shared and pinned)

$/bar/foo/b.txt (deleted)

$/bar/foo/c.txt (pinned)

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz/foo/ (Shared)

$/xyz/foo/a.txt (Shared and pinned)

$/xyz/foo/b.txt (deleted)

$/xyz/foo/c.txt (pinned)

Likewise, if we unpin and branch a.txt in one of the shared folders, both of them get branched from the other a.txt links.

$/bar/foo/ (Shared)

$/bar/foo/a.txt

$/bar/foo/b.txt (deleted)

$/bar/foo/c.txt (pinned)

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz/foo/ (Shared)

$/xyz/foo/a.txt

$/xyz/foo/b.txt (deleted)

$/xyz/foo/c.txt (pinned)

Note that even though $/bar/foo/a.txt and $/xyz/foo/a.txt have their primary shares broken, they are still have secondary shares, so any change made to one is made to the other. They are just not shared with the other a.txt files any longer.

Finally, suppose we re-share $/bar/foo/a.txt with $/a.txt and then branch $/bar/foo from $/xyz/foo. This results in:

$/bar/foo/

$/bar/foo/a.txt (Shared)

$/bar/foo/b.txt (deleted)

$/bar/foo/c.txt (pinned)

$/a.txt (Shared)

$/proj/a.txt (Shared)

$/xyz/foo/

$/xyz/foo/a.txt (Shared)

$/xyz/foo/b.txt (deleted)

$/xyz/foo/c.txt (pinned)

$/bar/foo and $/xyz/foo are no longer shared and changes made to one do not get reflected in the other. However, the a.txt files in each are still shared with each other, because they had a primary share prior to the folder branch.

Query Description

The Query Description is displayed beneath the menu bar. The basic format of the description is:

[RECURSIVE] changes [ACTIONLIST] to [TOP], made by [WHO], [WHEN], including [WHICHFILES], with [COMMENTCRIT], sorted by [SORT].

  • [RECURSIVE] – Recursive or Non-recursive depending on selection in query.

  • [ACTIONLIST] – If the current query is filtering by actions, the actions are collected into a list and displayed.

  • [TOP] – The complete repository path and name of the file or folder which defines the top of the query.

  • [WHO] – If the current query is filtering by user, the list of the filtered users is displayed.

  • [WHEN] – If the current query is filtering by date, the filtered date is displayed.

  • [WHICHFILES] – If the current query is filtering by filename, the filter is displayed. For example: only files/folders with names containing ‘gr’

  • [COMMENTCRIT] – If the current query is filtering by comment, the filtered comment is displayed.

  • [SORT] – The name of the column on which this query is sorted, followed by the word ‘ascending’ or ‘descending’.

Rename and Working Folders

If the working folder is inherited, the rename will alter the current working folder and the rename will act as if you changed the working folder. This means that all the files in the selected folder will have their status changed to Unknown or Missing. If you specifies a working folder for the folder that is renamed, the working folder and the status of all the files in the folder will not change.

For example, if $/foo has a working folder specified as c:\foo, then $/foo/bar inherits c:\foo\bar as its working folder. If $/foo/bar is renamed to $/foo/barnone, its new working folder is c:\foo\barnone, and no files in $/foo/barnone exist, so their status is all Missing. However, if $/foo/bar already had a working folder of c:\someotherfolder, then renaming $/foo/bar has no effect on its working folder – it is still c:\someotherfolder and the files all retain their current status. Note this logic applies recursively to all folders below a rename, since they all could have different working folders after a rename

Share Branch

If the Share Branch is on a shared folder, it is implied recursive. If a folder branch is applied to a Secondary Share on a folder, the operation is a Copy Branch rather than a Share Branch, meaning you can only Share Branch from a Primary Share.

For example: If a share was done on $/foo and a branch is applied to $/foo/subfolder, then the Copy Branch command is invoked on $/foo/subfolder, and you would choose another location to copy the folder to. $/foo/subfolder would remain shared after such a branch. Breaking the share must be done at $/foo. This applies to any files as well. For example, $/foo/abc.txt would invoke a Copy Branch on abc.txt, not a Share Branch.