Hello Robert,
Robert Butterfield wrote:
Hi,
Excuse me if I ask dumb questions, but I am just starting with Trac.
I would like to use Trac with a Mercurial based Distributed SCM workflow.
Great !
I am working with the latest dev 0.10 trac (both trunk and
sandbox/vc-refactoring) and would like to test the View Revision
selector that is Mercurial specific, supporting branch and tag
selection, as shown in:
http://projects.edgewall.com/trac/attachment/wiki/TracMercurial/hg-plugin-browser.png
I assume this code would be in browser.cs. Is there some code that I
am missing for this feature in the Source Browser? or does there need
to be some API issues resolved between the trunk and the plugin to
cope with these extra ui elements?
This feature (quick jump to a tag or a branch) has been temporarily
removed,
but reintroducing it is really the next thing I'll do on the
vc-refactoring branch.
Note that at this point (r3014), only the trunk is needed for the
TracMercurial
plugin, as the two changesets on the vc-refactoring are actually about
supporting
#1830 (handle non fully self-contained scoped SVN repositories).
Additionally I would like to be able to commit wiki changes and
tickets locally and then be able to merge them together at a central
mercurial repository when online.
That would be extra cool :)
See http://projects.edgewall.com/trac/ticket/1465
Don't hesitate to add your requirements there.
I assume this is really the TighterIntegrationwithRepository changes
that are in the future.
http://projects.edgewall.com/trac/wiki/TighterSubversionIntegration
I have seen some discussion of multiple repositories or special places
in the main repository to store wiki pages and tickets, has the next
step in the roadmap been resolved and if so where would I start to
contribute?
Well, I guess a new branch would be needed for that.
We should discuss it on the Trac-Dev mailing list (1).
One quick idea is since Mercurial has the potential for multiple heads
in a repository we could have specially named heads for wiki and tickets.
Another option might be to build a mercurial extension similar to the
mqueue patch queue extension to store Trac data in the .hg area.
The vc-refactoring that has already taken place might allow the
Repository plugin to resolve whether there is only one repository or a
separate wiki/ticket store, allowing the strengths of each repository
type to be used correctly.
There are many options at this point, of course.
Ideally, one should be able to "compose" different kind of versioning
systems
for different needs. E.g. a Trac set up to browse the corporate SVN
repository
should still be able to use a Mercurial backend for the storage of its data.
This should not be a problem as the API for the storage will probably have
to be quite different from of trac/versioncontrol/api.
It seems to me that retaining the wiki history with the repository
would facilitate cloning of entire Trac/repository projects, the SQL
would provide a performance cache only.
Exactly.
-- Christian
(1) http://lists.edgewall.com/mailman/listinfo/trac-dev/
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
