Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A fine-grained method to track line level change history in Version Control Systems

IP.com Disclosure Number: IPCOM000209489D
Publication Date: 2011-Aug-08
Document File: 8 page(s) / 153K

Publishing Venue

The IP.com Prior Art Database


The article introduces a more precise view on the code change history to developers. It tracks line level line change history rather than the general file level change history. This can help developer avoid regression issues before committing the code and significantly improve the productivity in sofeware development.

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

Page 01 of 8

A fine-grained method to track line level change history in Version Control Systems

[Problem, known solution, related ART, drawbacks]

Nowadays, Version Control System (VCS) plays a very important role in team development, especially when a production has a great many developers to work together and has a very big and complex code base with a long iteration history. Current VCS production track a file change history rather than a code-line change history. Forinstance, when click "Show log" or "Revision graph" in TortoiseSVN, we can see the records that represents in which revision a file has been changed. That is coarse-gained because if we are focusing on codes bug fixing, it can not reveal which revision relates to only a code-line's modification. When a developer meets such requirement, the common solution is to browse each revision of the file that contains the code-line, open and track whether or not this line of code was modified in that revision by eyes. The experience is shown as follows:


Page 02 of 8

(This page contains 00 pictures or other non-text object)

Figure 1 Bad experience in tracking a code-line change history

From Figure 1, a developer wants to check the line of "fun" method signature changes, so he has to:

1. Retrieve the revision history of the file "HelloFun.java" which contains the line of "fun" method.

2. Request the diff file that describes what changed in one revision, for example 5600.

3. Retrieve the diff file of one revision of that file and check by eyes to see if this revision has any changes in the line that contains "fun" method definition. If not, back to step 2 and check the next revision 5599.

Finally, he found out that this line is only changed in revision 5599 and 5595, but actually this course wasted four times SVN Diff


Page 03 of 8

requests/responses for 5600, 5598, 5597 and 5596. The drawbacks are apparent:

- Slow in diff operation;

- Redundant connection access and data transfer;

- Change history checking needs people intervention, so it is easy to bring mistake.

The related arts that help developers improve the bad experience can divide into 2 categories: one is VCS based full text search, and the other one is the code blame function.
- The disadvantage of former solution is, such as svnquery, suppoSE, OpenGrok, GIT provided, search using keyword always not accurate, we always get a lot of noise results returned.
- The latter one is only shows in which revision the line is added to the file and can not reveal a change history hierarchy, developer still need manually check the revisions.

[Core idea]

This idea introduces a fine-grained method to track the code-line changes history instead of file level diff view in version control system. It caches the revision differences in local repository and keep synchronized with the remote VCS server. The key idea is that we analyze the diff files so that the client user can view the whol...