Wishes for a code tracking system

Designer's notes #13 - Home - Prev - Next
Øyvind Teig, Trondheim, Norway (http://www.teigfam.net/oyvind/)

Line level track-tags

Version control systems handle differences between some previous version of a file and some other version. Most often we need to find out when some particular change in the code was done. There may be some problem that we thought we had fixed, which may be ok now, but we aren't sure what's really happening.

I have in an earlier note [11] pointed out some wishes for a diff & merge program. Here, I try to outline a few wishes with respect to revision or version control and diff & merge, here summed as code tracking, adding some meaning to the code tracking term already in use.

I do not think that tools like MKS Source Integrity or StarTeam from Borland have the features mentioned here.

Contact info etc.

If you plan to use any of this, or like what you read, please help yourself. I think I copyleft these ideas, meaning I would appreciate being credited in a byline. Should any of the ideas not be new here, it is without my knowledge. Any feedback certainly is welcomed. Especially if I have invented something impossible!

Source level track-tags

Diff programs only see differences. They are line based (at least for the textual diffs). The user has no explicit control. Lines and letters are seen as added or removed. That's all.

I suggest here that the user may insert a predefined tag, like XYZSERV-e0034 into his source code (wrapped in a "comment"). This tag may come from a track system or delivered by a central server. The sequence must be unique and probably just an incrementing number. The user then decorates his code at places of interest; that the code "(around) here" has something to do with that tag. There could be some sort of lazy syntax, to signify blocks (from-to, range, around here, excatly here etc.) of lines. When such a fixed and rewritten file is "checked in" to the revision control system after editing, the change is easily viewed there. This may be traced forever.

The crux is that tags should be decorated into all appropriate files, not just one. Quite often a change in functionality or an error fix touch more than one file.

Observe that these track-tag fields constitute a fold variant type. The concepts here may be viewed together with [11] .

Tag survival and diff & merge

The tags just mentioned, even if they are traceable forever, would not be visible forever at any stage. I suggest a diff & merge system where the tag-list map is visible as headings like XYZSERV-e0034, and all the associated files listed below. These lists could be seen as file, line number(s), contents lists. This would be a many-dimensional list. The tool that extracts this list over a project with files, would have to look deep into the diff history of all files.

Observe that some already tagged lines would also be deleted by a new modification, or even partly deleted. This makes this difficult.

Still I would like the tag-lister to list all tags in the history of all files. At least until they are deleted for inclusion in the list. Remember, they would reside in the version control forever (i.e. until that system is zeroed).

The merge function could be used to have certain changes undone. If the user sees that this is ok for all influenced files, this could make sense (with redo).

26.Sept.07 (initial)
27.Sept.07