Cloak or Other Inactive Indicator

[AjarnMark]

We have numerous top-level folders spread across a half-dozen repositories. Several of those top-level folders represent application code that is no longer maintained (typically the application has been retired). I also have several sub-folders of active top-level folders, that contain code that is no longer maintained, such as old branches that have long ago been merged back to their trunks and newer (active) code and branches are out there.

I would like to provide some sort of visual cue to all the users of the repositories so they can quickly see that a folder is considered dead. I was thinking of using the Cloak command. Is this a good use for Cloak? Do you have a better suggestion?

Thanks!

[lbauer]

Cloak would be fine -- except that it is a user-specific setting. If you cloak folders, only you will see your cloaks.

A couple of other ideas:

Delete the folders/branches. They will still be in the repository/database, and you can undelete them at any time by right-clicking on the parent folder and selecting ->Properties->Deleted Items.

Or, you could rename these folders so they appear at the bottom of the folder tree, as in xFolder.

[AjarnMark]

OK, thanks. I didn't realize that cloak was user-specific. That's good to know.

As a follow-up, if I rename the folder, and then later someone is browsing the Item tracking notes, if they click on the file link that is added to the comment during check-in (when linking check-ins to Items) is the system smart enough to make that still work or will it be broken because the folder name has changed?

[lbauer]

Hmm. Good point. No, the system doesn't track the folder name change. When I tried this I got FailObjPathInvalid.

Let me check with our developers to see if there are other options here.

[jeremy_sg]

Just to chime in on this, I don't think that cloak is really what you want.

I would recommend (certainly for the old branches) that you just delete them. Delete is not a permanent operation, and can be undone. There are several points at which the performance of Fortress is related to the number of files and folders that are currently in the repository. Reducing that by deleting old code is a great way to improve performance. Please note, you don't need to obliterate the deleted branches, just leave them as deleted.

As for old products, delete would work for that as well. If that's unacceptable, you could create a new folder (we use the name zzzMothballed) and move unused projects into it.

[AjarnMark]

Thanks for the ideas Jeremy. I realized as I read your suggestions, that there are perhaps two categories of old branches. One is "so old that looking back at it would be nearly meaningless" and deleting those is a good solution. The other is "old, but I may still want to look at something about the history or DIFF" so I wouldn't want to delete those. Maybe moving them or renaming them as Linda suggested will be my best approach. I just have to decide what the decision points are when I don't care about links in Item Tracking still working, and when I don't care that I can't review it at all without the effort of undeleting (and then later cleaning it out again). Obviously this is not a critical issue, it's more of a desire to clean up and organize things. If you guys ever think about a feature like being able to color-code folders in the GUI, that could work for this, too. For the most part, this does not affect any of my developers, as they usually use the IDE integration, but I tend to look at things in the GUI as I'm thinking about the whole trunk/branch relationship and how to setup my successor for success should I win the lottery and disappear to a tropical island.

[lbauer]

I've logged feature request 14062 for the ability to color code folders. This could be a useful feature for many users. Thanks for the suggestion.