Opened 19 years ago
Last modified 13 years ago
#1492 closed enhancement
support for non-linear changeset sequences for monotone-like VCS — at Version 23
Reported by: | anonymous | Owned by: | Christian Boos |
---|---|---|---|
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@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
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:
- Previous change / Next change links
- 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
Change History (23)
comment:1 by , 19 years ago
Summary: | monotne support → monotone support |
---|
comment:2 by , 19 years ago
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:4 by , 19 years ago
Severity: | normal → enhancement |
---|
comment:5 by , 19 years ago
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 by , 18 years ago
Component: | general → version control |
---|---|
Owner: | changed from | to
comment:7 by , 18 years ago
Milestone: | → 2.0 |
---|
comment:8 by , 18 years ago
Cc: | added |
---|
comment:9 by , 18 years ago
Cc: | added; removed |
---|
comment:10 by , 18 years ago
Cc: | added; removed |
---|
comment:11 by , 18 years ago
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 by , 18 years ago
Description: | modified (diff) |
---|---|
Milestone: | 2.0 → 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.
follow-up: 15 comment:14 by , 17 years ago
Owner: | changed from | to
---|---|
Summary: | monotone support → 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:
- Previous change / Next change links
- 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 by , 17 years ago
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.
- 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.
- 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
- http://lwn.net/Articles/140350/ (gitk),
- http://en.wikipedia.org/wiki/Image:Hgk.png (hgk), or
- http://samba.org/~jelmer/bzr/bzrsvn-merge.png (bzrk)
for examples of how it could look like.
comment:16 by , 17 years ago
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.
follow-up: 18 comment:17 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
Milestone: | 0.11 → 0.12 |
---|
comment:20 by , 15 years ago
Cc: | added |
---|
As the VcRefactoring is scheduled for 0.12, shouldn't this ticket also be?
comment:21 by , 15 years ago
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 by , 15 years ago
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).
comment:23 by , 15 years ago
Description: | modified (diff) |
---|---|
Milestone: | 0.13 → 0.12 |
Priority: | normal → high |
Severity: | normal → 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.
See also the Darcs support patch in ticket #638. It contains a generic SCM backend interface that the Monotone support probably could implement.