[ER] Alternate revision log

[Christian Boos]

The problem

Currently, the revision log is showing the history of a given node, i.e. a path from a given revision.

I'd like to see the revision log being more focused on the history of a given path. This would be especially relevant for tags and branches.

An example

Let's consider the following use case, which corresponds to a tag that has been created, then "moved":

• work on the trunk, till r126, reaching a stable release point
• decide to tag it as /tag/release1: svn cp -m "create release1" trunk tags/release1 → r127
• just before shipping, detect and fix a critical bug in r127
• decide to move the tag:
  • svn rm -m "delete tag" tags/release1 → r128
  • svn cp -m "re-create tag" trunk tags/release1 → r129

Now, what I currently see when browsing the revision log for /tags/release1 is:

• r129 "re-create tag"
• r127 "fixed critical bug"
• r126 "release point reached"
• r125 "did something"
• …
• r1 "initial import"

Now, what I'm really interested in is:

• r129 "re-create tag"
  • r127 "fixed critical bug"
• r128 "delete tag"
• r127 "create release1"
  • r126 "release point reached"

Other usages

This alternative view could also be used when the regular one gives a "path not found in that revision" error: it might be that the user wants to see the history of a path he knows has existed at some point in time in the repository, but was deleted since.

Note: this applies to Subversion, I'm not sure it's relevant for other version control systems

[Matthew Good]

I think that we should discourage this manner of using tags. Tags should be a snapshot of the code; if a tag can change over time it loses meaning. The fact that your tag existed both with and without the bug fix could cause confusion.

I think the better approach would be

• create tags/1.0
• find critical bug'''
• copy tags/1.0 to branches/1.0
• fix the bug in the branch
• copy branches/1.0 to tags/1.0.1
• release 1.0.1 with the bug fix

I understand that not everyone is going to follow the same release procedures, but I don't think that we should encourage people to use tags in this way.

[Matthew Good]

For the other suggested use of finding the history of a currently deleted file, I wonder if a more useful solution would be to provide a mechanism for searching filenames in the repository. This would have many other applications besides just looking for information on deleted files, but should be able to solve that problem as well.

Ideally the file search would be able to group files together that were descendant from a common node so that you could see if a file was moved or copied between several locations in the repository.

I could possibly see this search interface displaying the revisions where the paths were created and deleted, though I don't think it should display too much history that would clutter things, since the complete history of each file could be obtained through the current revision log.

Actually, this may be sufficient to satisfy the original intent of this ticket, though I think it focuses on a slightly different goal that would be more globally useful (IMO).

Feedback and interface ideas would be appreciated.

[Christian Boos]

I agree, a tag should be immutable… in theory, but in real life, moving a tag is something that simply happens time to times. Even CVS allowed you to move a tag if that was really needed. Anyway: Trac should impose as little as possible on a team's established development process and policies…

The point is, when that happens, it's really not easy to figure out it happened, especially with the traditional tools (svn command line, TortoiseSVN).

Perhaps the following scenario be more convincing: instead of tags, consider branches. When you maintain one or several branches, the usual approach is to make specific changes on the branch and also periodically sync with the trunk. For example, that's how I started to do with my xref-branch. However, I discovered that syncing in the changes from the trunk in the branch did bring a huge changeset (all the changes from the trunk since the creation of the branch) which is not very meaningful by itself. The next time I'll synchronize with the trunk, I would like to take a different approach: make a diff, delete the branch, recreate the branch by copying the current trunk, apply the diff, merge and commit this. The advantages are clear: not only less resources are used, but the semantic of the changesets is also clearer: the last changeset would be a patch against the trunk, and will summarize all the differences relative to the feature being worked on. The only disadvantage is that the history of the branch itself is lost, at least with the traditional node revision log approach. With the proposed path revision log, one could easily follow the branch history in that case.

I believe that in general Trac can be used to offer some advanced views on the Subversion repository. If I understood correctly your idea about file searching in the repository, you would like to see all the copy to information for a given node (i.e. what TortoiseSVN calls the Revision Graph). That's also something that fits in that category of advanced view of the repository (and I'll create a ticket for it).

Back to the topic of this ticket, I'll attach the patch that provides this functionality, and some screenshots.

[Christian Boos]

patch made on [1515]

[Christian Boos]

traditional view of the revision log (a little bit enhanced, though)

[Christian Boos]

view of the revision log staying focused on a given path, through all the history of the repository

[Christian Boos]

Updated screenshot

[Christian Boos]

Updated screenshot

[Christian Boos]

Fixed in [1540]. See this ticket for a screenshot of the new feature.

[Christian Boos]

Note that this should be reimplemented based on the VC cache (see VcRefactoring), as doing this using the svn bindings is dramatically slow…