Edgewall Software
Modify

Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#1492 closed enhancement (fixed)

support for non-linear changeset sequences for monotone-like VCS

Reported by: anonymous Owned by: rblank
Priority: high Milestone: 1.0
Component: version control Version: devel
Severity: major Keywords: revision dag dvcs
Cc: lapo@…, fcorreia@…, jsceballos@…, gwk.rko@…, hvr@…, thomas.moschny@…
Release Notes:

Added a visualization of the revision graph in the revision log.

API Changes:

Description (last modified by cboos)

Implementing support for Monotone-like VCS (like hg, git, bzr) in Trac has to overcome the assumption of a linear succession of changesets, inherited from Subversion.

This assumptions shows in a few places:

  1. Previous change / Next change links
  2. Revision log view

(from comment:5)


This ticket was originally a request for Monotone support

Considering 2.0 enhancements it would be great to support monotone http://venge.net/monotone/ SCM system. It grows very fast and was considered by Linus Torvalds to replace BitKeeper?, in fact git (a fast written Linus's tool to manage Linux sources w/o any SCM) was desinged based strictly on ideas behind monotone.

Development of a trac plugin for connecting to a monotone repo has been started, see http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone

Attachments (3)

1492-hg-parent-revs-r9946.patch (1016 bytes) - added by rblank 4 years ago.
Patch for mercurial-plugin-0.12 to provide Repository.parent_revs().
log-graph.png (140.7 KB) - added by rblank 4 years ago.
Example log graph (from the hg-crew repository).
trac-git-octopus-merge-graph.png (55.1 KB) - added by hvr@… 4 years ago.
graph sample for octopus merge

Download all attachments as: .zip

Change History (46)

comment:1 Changed 9 years ago by anonymous

  • Summary changed from monotne support to monotone support

See also the Darcs support patch in ticket #638. It contains a generic SCM backend interface that the Monotone support probably could implement.

comment:2 Changed 9 years ago by cboos

Well, no: There's an official generic SCM backend interface currently in current development version of Trac, and this is the one to implement. See source:trunk/trac/versioncontrol/main.py#latest

comment:3 Changed 9 years ago by cboos

s/currently sorry :)

comment:4 Changed 9 years ago by vittorio

  • Severity changed from normal to enhancement

comment:5 Changed 9 years ago by njs@…

As current head cat-herder/developer behind monotone, I thought I'd put in a word here… I'm definitely interested in seeing this happen (it'd be nice to use trac for monotone development itself!). I thought a bit about adding it myself, but simply don't have the time; but, if someone else decides to take a shot at it, we'd definitely be interested in helping provide info, fixing interfaces to be more usable, etc.

Monotone might be an interesting target in any case, since it's one of the most different VCSes from subversion — unlike subversion it has first-class branches and tags (so a monotone repo is not a simple singly-rooted tree), and unlike, say, darcs or arch or bzr-ng, it has microbranches (so even within a branch, history is a DAG, not a line). Looking at source:trunk/trac/versioncontrol/api.py#2127 , the current API seems to assume that history is a straight line (e.g., that each revision has exactly one predecessor and successor); this simply isn't true for several of the new generation of VCS tools. So if you can support monotone, you can probably be pretty sure that your design can support anything :-).

comment:6 Changed 9 years ago by cmlenz

  • Component changed from general to version control
  • Owner changed from jonas to cmlenz

comment:7 Changed 9 years ago by anonymous

  • Milestone set to 2.0

comment:8 Changed 9 years ago by lapo@…

  • Cc lapo@… added

comment:9 Changed 8 years ago by anonymous

  • Cc jm3@… added; lapo@… removed

comment:10 Changed 8 years ago by anonymous

  • Cc lapo@… added; jm3@… removed

comment:11 Changed 8 years ago by moschny

Development of a trac plugin for connecting to a monotone repo has been started, see http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/.

comment:12 Changed 8 years ago by cboos

  • Description modified (diff)
  • Milestone changed from 2.0 to 0.11

I'm setting a milestone here for the improvements on the versioncontrol API and web interface, not for the plugin itself, of course.

comment:13 Changed 8 years ago by moschny

For the problem of long revision ids, see #3533.

comment:14 follow-up: Changed 8 years ago by cboos

  • Owner changed from cmlenz to cboos
  • Summary changed from monotone support to support for non-linear changeset sequences for monotone-like VCS

As mentioned in comment:5, the biggest challenge for integrating Monotone-like VCS (like hg, git, bzr) in Trac is the assumption of a linear succession of changesets.

This assumptions shows in a few places:

  1. Previous change / Next change links
  2. Revision log view

For 1. it's possible to follow the first parent/first child, as I've done in TracMercurial. In case this is not what is wanted, it's always possible to follow explicitly the second parent or another child from the changeset view.

For 2. the linear view in the TracRevisionLog is really problematic. There should be at least some indication that a given changeset is either a branch point or a merge point (or both, of course).

comment:15 in reply to: ↑ 14 Changed 7 years ago by moschny

Replying to cboos:

As mentioned in comment:5, the biggest challenge for integrating Monotone-like VCS (like hg, git, bzr) in Trac is the assumption of a linear succession of changesets.

Agreed.

  1. Previous change / Next change links

For 1. it's possible to follow the first parent/first child, as I've done in TracMercurial. In case this is not what is wanted, it's always possible to follow explicitly the second parent or another child from the changeset view.

We should remove the "previous" and "next revision" links, and instead only have the set of "parent" and "child" links.

But there's more than that. In the vc api we should clearly separate the notions of "before/after" and "parent/child". As you wrote somewhere in a comment, these two are not interchangeable even for subversion, and they are surely not for Monotone.

However, both concepts may be needed. The timeline clearly uses the first concept, while the changeset view relies on the second.

  1. Revision log view

For 2. the linear view in the TracRevisionLog is really problematic. There should be at least some indication that a given changeset is either a branch point or a merge point (or both, of course).

What people really want (but that might be some work to get it implemented) is a gitk/hgk/bzrk like display of the history, be it for repositories (resp. branches) or single nodes.

See

for examples of how it could look like.

comment:16 Changed 7 years ago by moschny

The other possible visualization method preferred by many people is a graph of revisions, similar to that provided by the th:wiki:RevtreePlugin. In case of Monotone, the "standard" visualization is that generated by ViewMTN and monotone-viz.

comment:17 follow-up: Changed 7 years ago by cboos

The discussion about the visualization pertains rather to #1445. As noted there, I think that while a graphical representation is neat, we should first concentrate on getting that information available in a clear way in the traditional TracRevisionLog HTML view.

comment:18 in reply to: ↑ 17 Changed 7 years ago by moschny

Replying to cboos:

As noted there, I think that while a graphical representation is neat, we should first concentrate on getting that information available in a clear way in the traditional TracRevisionLog HTML view.

Sure. But instead of inventing a new way to linearise a dag like revision history, we should have a look at what existing ("..k") tools do; that was the intention of my comment:15.

comment:19 Changed 7 years ago by cboos

  • Milestone changed from 0.11 to 0.12

comment:20 Changed 5 years ago by FilipeCorreia

  • Cc fcorreia@… added

As the VcRefactoring is scheduled for 0.12, shouldn't this ticket also be?

comment:21 Changed 5 years ago by cboos

  • Keywords revision dag dvcs added

Well, the VcRefactoring page describes the on-going effort to improve the (D)VCS support in Trac. As such, it's not strictly tied to 0.12 or any milestone in particular.

For 0.12, the most likely improvement in the vc refactoring area will be the MultipleRepositorySupport, so having this ticket scheduled for 0.13 is actually a good fit.

comment:22 Changed 5 years ago by cboos

Always struggled to find a readable and not too complex way to display DAG information in the TracRevisionLog… Maybe something like this:

Maybe we could add this using a sub-table: 

|| Rev || Date  || Author || Log Message                        || 
|| 100 || ././. || xyz    || merged bugfix #123 from stable     || 
||     ||       ||        ||                                    || 
||     ||       ||        || ||Rev||Date||Author||Log Message|| || 
||     ||       ||        || ||98 || ...||xyz   ||bugfix #123|| || 
||     ||       ||        || ||97 || ...||xyz   ||clean-up   || || 

(...) in merge revisions, 
we would show the first few changesets from the incoming branch and 
simply have a link to "jump" on the revision log of that incoming 
branch for seeing more ancestors (and incoming branches for that branch).

(from googlegroups:trac-users:7fe27e8c64b8fd5c)

comment:23 Changed 5 years ago by cboos

  • Description modified (diff)
  • Milestone changed from 0.13 to 0.12
  • Priority changed from normal to high
  • Severity changed from normal to major

Instead of showing directly a sub-table, we could show a special marker in the row if a changeset is a merge changeset. We could also have a "(show merged revisions)" link at the bottom of the merge message. That link could either link to another log page, or (with Javascript enabled) fetch that log with an XHR and insert it in place, like above.

Note that for Subversion 1.5+, we could support svn log -g in a similar way. For efficiency, we should probably also record if a given changeset was a merge changeset, in the cache.

comment:24 Changed 5 years ago by cboos

  • Cc jsceballos@… gwk.rko@… added

#8478 was closed as duplicate (suggested comment:22 approach).

I currently favor the comment:23 approach.

Also, this plays well with the recent suggestion of Georg to show the changesets belonging to the current branch, in Mercurial (hg log --follow-first).

comment:25 Changed 5 years ago by cboos

  • Milestone changed from 0.12 to next-major-0.1X

comment:26 Changed 4 years ago by cboos

  • Milestone changed from next-major-0.1X to 0.13

If there should be only one new feature for the versioncontrol subsystem in the next major release, that should be this one ;-)

comment:27 Changed 4 years ago by hvr@…

  • Cc hvr@… added

comment:28 Changed 4 years ago by rblank

I would like to start working on this. As a first step, how about simply adding graph information to the revision log, similar to the graph view in Mercurial? This would probably be relatively easy to implement:

  • Add methods to get the parent / child relationships between changesets.
  • Use that information to display the graph.

This would already make Trac much more usable with DVCS.

comment:29 Changed 4 years ago by rblank

I have a proof-of-concept running here, using SVG for graph display (but this could easily be adapted to use a <canvas> instead). It uses a similar algorithm as Mercurial, generalized to the n-parent case. For a Mercurial repository, it displays the same graph as Mercurial itself.

I need to clean it up a bit, and find a way to align the graph items with the corresponding revision log rows. When that's done, I'll put it up here for review.

Changed 4 years ago by rblank

Patch for mercurial-plugin-0.12 to provide Repository.parent_revs().

Changed 4 years ago by rblank

Example log graph (from the hg-crew repository).

comment:30 Changed 4 years ago by rblank

I have pushed a first implementation using SVG Web to my work clone in the ticket-1492-svgweb branch:

  • Adds Repository.parent_revs() to return the direct parents of a revision.
  • Renders the graph as SVG when viewing the log of the root of a repository.
  • Works with all major browsers (Firefox, Chrome, Opera, Safari, IE).
  • Requires JavaScript on all browsers, and additionally Flash Player on IE.

1492-hg-parent-revs-r9946.patch implements Repository.parent_revs() in mercurial-plugin-0.12.

Using straight embedded SVG works great on Firefox, Chrome, Opera and Safari, and would be ideal as it doesn't even require JavaScript, but I wasn't able to make it work on IE. That's why I started trying alternatives. Flash is far from ideal, so I'm going to experiment with Silverlight on IE.

Using <canvas> would probably be doable on all browsers, but will require JavaScript.

Here's an example of the output on Firefox (showing a part of the hg-crew log). Feedback very welcome.

Example log graph (from the hg-crew repository).

comment:31 follow-ups: Changed 4 years ago by hvr@…

I implemented .parent_revs() and .children_revs() in trac-git-plugin:7c514e5… and it seems to work quite fine with my git plugin as well… great work, can't wait to see it hitting trunk :-)

comment:32 in reply to: ↑ 31 Changed 4 years ago by rblank

Replying to hvr@…:

I implemented .parent_revs() and .children_revs() in trac-git-plugin:7c514e5… and it seems to work quite fine with my git plugin as well…

Thanks for the very quick feedback! Note that children_revs() isn't actually needed, so I didn't define it in the API, but we might add it for symmetry.

comment:33 in reply to: ↑ 31 Changed 4 years ago by rblank

Replying to hvr@…:

it seems to work quite fine with my git plugin as well…

One more thing: could you please try and see how an octopus merge is rendered?

Changed 4 years ago by hvr@…

graph sample for octopus merge

comment:34 Changed 4 years ago by anonymous

sure, attached a screenshot showing the 8-legged octopus merge commit 45c448a1c0bed9c7eab6064493a7c5d94defcafd from linux kernel git repository…

comment:35 Changed 4 years ago by rblank

Thanks! It's not pretty, but still readable, and the algorithm seems to work. I assume 8-legged octopus merges shouldn't be too frequent (git newbie here).

I am working on a second version using <canvas>, with explorercanvas for IE. That's probably the best solution, as it's JavaScript-only.

comment:36 Changed 4 years ago by thomas.moschny@…

  • Cc thomas.moschny@… added

comment:37 Changed 4 years ago by rblank

Here's an updated version in the ticket-1492-canvas branch, with the following improvements:

  • Uses a <canvas> for rendering, so this is a JavaScript-only solution. It gracefully degrades if JavaScript is disabled.
  • Colors can be configured.
  • Graph data is pruned to lower the page size.
  • Works well on FireFox, Chrome, Opera and Safari.
  • Uses Explorer Canvas on IE, but the result is not yet satisfactory. The graph only seems to appear in quirks mode, and for some reason, the height of the rows in the log is larger than in other browsers (and different between IE7 and IE8!), so the graph doesn't align.

I'm quite convinced that <canvas> is the way to go. Rendering on IE still needs some work (including fixing the weird row height bug). Feedback welcome.

comment:38 Changed 4 years ago by rblank

The current tip of the branch now works well (most of the time) with IE8. Unfortunately, the fix breaks the .change column on IE7, and the latter still has rows that are too tall.

comment:39 Changed 4 years ago by rblank

For review, here's a diff of the branch against trunk.

comment:40 Changed 4 years ago by rblank

  • Resolution set to fixed
  • Status changed from new to closed

The <canvas> implementation has been committed in [10330], with some minor tweaks to the presentation. This was the most pressing missing feature for DVCS, so I'm closing this ticket. Please open new tickets for other feature requests.

comment:41 Changed 4 years ago by rblank

  • Owner changed from cboos to rblank

comment:42 Changed 4 years ago by rblank

Oh, and for a (not too branchy) demonstration, see rblank.

comment:43 Changed 4 years ago by rblank

  • Release Notes modified (diff)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain rblank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from rblank to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.