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.
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).
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.
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’.
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
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.