Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Automated Deletion and Archiving of Source Files in a Software Control Management System

IP.com Disclosure Number: IPCOM000246008D
Publication Date: 2016-Apr-26
Document File: 2 page(s) / 22K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to enable a software configuration management (SCM) tool to provide the developer with the option to select/mark files for automatic deletion or archiving after a given period (e.g., 6 months).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Automated Deletion and Archiving of Source Files in a Software Control Management System

Using a software configuration management (SCM) tool to version and control the source code for a software project is ubiquitous these days. It is for source code files to become outdated after completing major refactoring tasks and/or after introducing new changes.

For example, a DevOps team writes several Gradle* scripts using mainly the Java* language for the implementation of the different build tasks. After major refactoring work, most of the build logic in the scripts is rewritten in the Groovy* language. Because of this, several of the original Gradle scripts are now no longer needed. In addition, logic initially written for parsing and updating files is no longer needed given that new tools are now leveraged by build the scripts.

Though the outdated Gradle scripts could be just deleted or removed from the SCM repository, the DevOps team would like to keep these files in the repo for a while. The team does not feel comfortable removing these files yet and would like to have access to the files whenever performing a source code pull from the repo. After a predefined amount of time has elapsed, the team will feel comfortable with the removal and archiving of these older unused files.

In such a scenario, the team lead for the project typically creates a list with the names and paths of all outdated Gradle files and adds a reminder to an electronic calendar to remove these files after a period (e.g., six months). Another option for "implementing" a solution to this business need is to create a script that deletes the specified files if they become six months old. The script could be executed every night at midnight. Note that this option is very wasteful of compute resources and is prone...