Browse Prior Art Database

IPD: An early warning system for file version conflicts in Source Control Management systems that utilise sandbox and optimistic locking mechanisms Disclosure Number: IPCOM000199845D
Publication Date: 2010-Sep-17
Document File: 3 page(s) / 73K

Publishing Venue

The Prior Art Database


Disclosed is a scheme, designed for Source Control Management systems (SCM) that allow User sandboxes. These sanboxes provide an early warning mechanism for Users when they may be heading towards a conflict. This mechanism would, upon a use making changes to the file(s) in their repository workspace, poll other repository workspaces that target this stream, and warn all concerned Users that another User has made changes to the same file(s) in their respective repository workspaces. The mechanism allows Users to interact at the earliest possible moment and take action if desired.

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

Page 1 of 3

IPD: An early warning system for file version conflicts in Source Control Management systems that utilise sandbox and optimistic locking mechanisms

Many Source Control Management (SCM) systems today utilise an optimistic locking mechanism. From the Jazz online help:
Jazz source control uses an optimistic locking model that does not require a check out operation before you can modify files or folders. All files in a local workspace are normally writable. Modified files remain private to your repository workspace until you deliver them. Two concepts are to be understood here:

Local workspace: In which a person performs changes to a local copy of a file/folder
Repository workspace: A server copy of the User's workspace. This sandbox is stored on the SCM system outside of the main targeted stream.

    Changes made in a repository workspace, to files or folders, remain in an 'unresolved' state until they are checked in by the User. This does not, however, involve a delivery to the stream. Check-in here amounts to a synchronisation between the local workspace and the repository workspace.

    Each individual User can have one or more repository workspaces (akin to a sandbox) in which they can perform changes to the source code / files. Since locking is optimistic, many Users (or indeed, the same User) can make changes to a file in several repository workspaces.

    As the User makes changes to the source in a repository workspace, a diff is performed by the system, providing one or more Change Sets that can be delivered to the stream, or rejected to revert the files in the repository workspace to that in the stream.

    When a User delivers a Change Set to the stream, all other Users are notified of this Change Set. From this point onwards, they are presented with the option to accept the change, now performed on the stream, into their own repository (and local)


              . Should another User be working on a file in this change set, the User is now alerted of a conflict. The User who has not delivered their change set, is now no longer able to do so until a merge of the conflicting file versions is completed.

A combination of the following factors can lead to an excessive amount of time being spent on merging files:

User A spends a long time working on a file, making a large number of changes as part of a defect fix or new feature, and no delivery is made to the stream until the program is working as expected.

    User B, meanwhile, is also making changes to the same files. User B may change some common areas of code with User A
As a result:

One User will be burdened with an excessive merge cost, if last to deliver. The User who delivers first may have to work with the other to resolve ideas and conflicts about implementation in common code areas within the conflicting files.

It may even be the case that User A has spent a lot of time making the same alterations as User B, so while merging is simplified, the cost has already been borne by the team.

Page 2 of...