Preparing your result...
Loading...
Press Esc to dismiss this message

Method for tracking version control operations using filesystem monitoring functionality of operating system (18-Aug-2009)

Thumbnail
IP.com Prior Art Database Disclosure (Source: IPCOM)
Disclosure Number IPCOM000186385D dated 18-Aug-2009
Originally published in Prior Art Database
Disclosed by: IBM
Country: Undisclosed
Disclosure File: 3 pages / 273.4 KB / English (United States)

Majority of software development uses version control systems for keeping track of changes and team driven development. A very popular model for version control systems is to store master copy on a central (or clustered) server and checking out / extracting local working copies for development. After changes have been made to sources, they are checked in to central server. Typical problem is that once a local repository is checked out, all operations except for modifying the file (delete, rename, move) need to be done using tools related to the version control system. This means that they can only be done using tools provided with the version control system or using tools and Integrated Development Environments (IDEs) that are integrated with specific version control system. A common operation is to use tools such as file managers or code refactoring tools to operate on these files automatically - perform mass renames, update code and do several moves of the actual files. If these tools don't support a particular version control system, all changes need to be input manually to the version control system. In some cases, it is done by deleting old versions of the files and creating new ones, which causes all change history to be kept in old file and loosing association of actual file with complete change history.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Method for tracking version control operations using filesystem monitoring functionality of operating system

Disclosed is a method for using operating system's functionality to receive notifications about directory changes in order to track changes to version controlled files. This will allow using any available tools and/or Integrated Development Environments (IDEs) for managing source code of a project without having to integrate the tool with version control system or without performing part of file operations (such as rename, move, delete) manually.

Upon performing a checkout of a local repository, version control software needs to track locations where local repositories are checked out and register within the operating system to receive information about changes to these directories or any of their subdirectories. The service will track all changes to the filesystem other than file modifications. After performing a checkout, all filesystem changes performed on a directory or its subdirectory are tracked in a filesystem monitoring history - which can be a database, log file or any other means of storing this information.

In order to exclude changes that were correctly registered in the local repository metadata, the software can also track changes to local repository metadata. For example after a file has been renamed, if a proper modification has been done to the local repository's metadata (i.e. to files in CVS or .svn directories), then this change is removed from the filesystem monitoring history. Since it has already been reflected in the metadata, applying it second time will cause corruption.

When attempting to check in changes made to the local replica, version control software can either automatically use monitored changes or prompt the user on which changes should be committed - to avoid accidental deletes or problems caused by invalid monitoring of the filesystem changes.

Upon removal of a local replica, version control system no longer keeps track of the directory and unregister itself from receiving filesystem notifications.

An optional feature can be to add in filters to which events should be monitored and which should not - tasks could be skipped based on process binary name, by filename pattern, by specific operations or by any combination of these. This feature, however, is not mandatory and can be implemented either at filesystem monitoring component or can be applied when committing changes to the repository.

Another optional feature is creation of new files. Combined with filtering which events should be taken into account, it can be used to automatically add files created by IDEs and file management tools (such as Total Commander), but skip files done as part of build process or temporary files created by text editors/IDEs.

Sample operations:


Let's assume that a user wants to work on a...

(Source: IPCOM)
First page image
(Source: IPCOM)