Idea ID: 2870398

Better Handling of Defunct Files

Status : New Idea
2 months ago

For context, my organization uses Revert-To-Basis (purge) operations as a clean-up method in 2 cases:

1) Discarding changes which are no longer desired to files which themselves remain "backed"
2) Discarding files which, upon analysis, we decide should never have been promoted to the stream in question

By contrast, we use "defunct" to remove code which at one point was properly included in a given stream, but which further development has caused to be no longer desired. I.e. we determine that a module of code is no longer wanted, but remains of potential historical interest to the stream. However, the "defunct" operation leaves a lot to be desired.

1) When "Defunct" status is selected for a folder, the files within it do not become "defunct"; they instead become "stranded", which usually implies that something is wrong. This may not be the case when an entire code module is being intentionally retired.

2) Even if a folder and all of its contents are marked "defunct", the files will be marked as "stranded" even though their path remains valid in the Outgoing view. This means that if you have a stream structure like "Development" > "Test" > "Release", and you Defunct a folder and all of its contents, and promote them to the "Release" stream, the "Release" stream will still show these files as "Stranded", with the ongoing implication that something is wrong.

3) To even succeed at step number 2, you have to either defunct (and promote) the files first and then the folder afterward, or defunct/promote the files along with their folders in the same operation. Otherwise the files become actually stranded when their enclosing folder is promoted, and cannot then be promoted without undoing the promote of the folder.

All of this combines to leave members of my organization confused about the proper use (if any) of the Defunct operation. It's not actually recursive, and leaves enclosed files in a "stranded" state which seems to imply a problem when it's possible that no problem exists. More robust handling of the Defunct operation and/or a clearer explanation of how/when to properly use it would be very helpful.

Labels:

Streams
Usability
  • The problem would (mostly) go away if admins had a way to enforce a rename of the element as part of the defunct operation. Rather than rely on the user following team guidance to 'rename-before-defunct', AccuRev would append the Unix timestamp, or a user-defined string, etc., to the element name automatically when made defunct. It could be made optional at the admin level. There are other reasons you might want to do this besides avoiding stranded elements.

    Or Micro Focus could revisit the decision made years ago to allow the promotion of an element to a stream that had an element with the same name, provided the element in the stream had (defunct) status. Perhaps that wasn't the best solution after all.

    Or some combination of both.

  • Hello Brian

    Correct, thanks for keeping me honest. I should have said "The only way to end up with a (stranded) element  (file or directory/folder) via a promote, is via a defunct operation on a directory/folder, or an odd corner cases.  See "AccuRev® -Technical Notes" and the section Handling Stranded Elements for details https://www.microfocus.com/documentation/accurev/73/AccuRev_TechNotes.pdf

    Cheers,

    Dave

  • The only way to end up with a (stranded) element  (file or directory/folder)  is via a defunct operation on a directory/folder.

    Dave, the technical notes article 'Handling Stranded Elements' (link in my post above) lists several ways an element can become stranded with no defunct operation involved at all. The article is from v7.2. Has this guidance become obsolete?

  • Hello James,

      The only way to end up with a (stranded) element  (file or directory/folder)  is via a defunct operation on a directory/folder.

      Any defuncted or stranded element is no longer contributing its contents the streams below.

      To know if the action was intentionally done would be to check the Issue, and/or ask the developer that promoted the defunted directory/folder.

      A best practice is to promote the defunct content to a separate Issue.  The Issue should clearly state the developer's intent to defunct the element.

    Cheers,

    Dave

      

  • Dave- thanks for the feedback. I should have been more clear that I am *most* concerned with the top-level stream for a project, which forms the basis for my org's delivery of software to clients, and at which all delivered files become "member" status indefinitely. When a "defunct" folder is promoted to that level, all enclosed files become "stranded", and I'm not sure that there is any obvious way to flag such files as *intentionally* stranded, vs. files that were stranded as part of a mistake, which was (unfortunately) propagated all the way to the top of a stream hierarchy.

    If there were some kind of "subdefunct" status (similar to the "subtwin" status) to indicate that a stranded file is stranded because of a defunct, that would at least provide an easy shorthand to indicate intentional removal to project/configuration managers, which is the level at which I'm concerned.

    Meanwhile... I'll refer this whole discussion to the concerned group in my org and see if they think that carving out some time here is warranted.