Use Subversion (or the source repository) for Trac's data as well

[twenim@…]

Use Subversion for data repository like ​subwiki

[Christopher Lenz]

See TighterSubversionIntegration.

[florian.burka@…]

I think this would be great, but there seems to be no movement in this. Is this still planned or not?

[anonymous]

Added a attachment to TighterSubversionIntegration, which enables a svn wiki backend.

Usage:

create a directory in your svn repos, and add a line like this to the trac.ini file:

[wiki]
svn_root = /path/to/wiki/root/from/svn/scope/

dump all wiki files which trac-admin to this directory, and commit it.

Apply the patch and restart trac.

TODO

• Deletion of pages.
• Add the TimeLineEventProvider and ISearchProvider.
• Testing the authz support.

[anonymous]

I have read the TighterSubversionIntegration and WhySQLite page regarding the pros and cons of SQLite. FWIW, I'd like to see trac use SVN as its backend, mainly because I wouldn't have to use hot copy to backup the entire trac db. With our SVN repos using FSFS, we can do incremental backups using rsync. I'd like to be able to do this with trac also.

Also, if something like this were to be implemented, I'd rather trac use its own repo inside the trac folder, rather than store in a special place in our source-code repo. I don't like the idea of something else commiting to our repository. It is for our source ocde and I'd like to keep it that way. Possibly being paranoid but also trying to keep the repo 'as clean as possible'.

Thanks

Russell

[Fergus Henderson <fjh-mailbox-38@…>]

My company is currently using Twiki, but we're planning to switch over to Trac if/when this is supported.

[Christian Boos]

I'm going to update the TracObjectModelProposal with an API for object storage an revisioning.

[Emmanuel Blot]

A question about implementing an SVN backend: what about the search feature ?

[Christian Boos]

Here's how I see it (roughly):

• A pluggable storage backend for the Trac objects (content, properties), which will be able to do the versioning. That backend could be the DB as usual, but also any other repository backend. A simple FS backend could be possible too…
• A database cache for the latest values (queries, full text search). Maybe even some kind of history, too (property changes?).
• A filesystem cache for the attachements (when we need to do a send_file) and possibly other generated data.

The data stored in the last two components could always be rebuilt from the authoritative information in the storage backend.

[MBParker@…]

(This is my first post here, and, except for the lack of WYSIWYG, Trac is very cool BTW - love its Tracklinks and diff displays!, among other coolness)

​Google search for Trac store wiki pages led me to ticket:1465 which led me here.

Yes, I would very much like to see Trac store its wiki (and eventually all its data) in the source control system (as Subversion).

However, I read on ticket:1465 that on 04/22/05 04:58:06 cboos said "I always thought that it was not a good idea to re-create a (simple) versioning system for versioning Trac's content, rather than using SVN. Now I think it would be really a bad idea to re-create a "light" distributed versioning system, given the complexity of such a thing, and the fact that a good alternative exist. " However, on 01/24/06 07:52:17, I'm pleased to see he'd devising a plan.

I think it should be done. I understand its hard. To avoid conflicting IDs in the database, you probably would have to go to a dual layer ID system: instance_name+sequential_number, not just sequential_number; and you'd have to sync the database. But this is doable. And, as well as making a cleaner server (not using separate storage), as ticket:1465 points out it would also allow you to run the trac distributed with sync. And if for some reason subversion was short a feature or two, it would then be improved as consequence.

This is my take: Subversion looks like a solid thing - so stick with it. Or if some version control system is better (perhaps ​Monotone ), use that. But don't have the very tool (Trac) designed to manage repository versioning reinvent versioning as well. -Mike Parker, www.Cytex.com

[Russell Hind <rhind@…>]

My 2 reasons for wanting this are:

• We use rsync for backups of our FSFS repositories, it would be a lot easier if we could do the same with trac (especially to remote locations)
• I know nothing about SQL/sqlite or any other database stuff, but I can administer an svn repository (hence we are using it and not something else for our source code) so for me it would just make sense to store it in
  • The source code repo under a user defined path
  • A separate repo (I have no real preference here)

[Russell Hind <rhind@…>]

(Sorry, didn't realise I'd already posted part of this above)

Cheers

Russell

[anonymous]

It came as a complete surprise to us when we realized (before installing) that Trac-generated content (Wiki pages, Wiki history, issue tracking, etc.) is NOT stored in a Subversion system.

1. We'd like to use Trac's Wiki functionality to maintain project documentation, but we need this documentation to be part of the general project source data, under Subversion.

2. We want a simple system with few dependencies and a simple backup procedure for all generated content. A separate database (with its dependencies) for issues and for the Wiki content unfortunately does not meet this need.

Trac looks awesome and we were so close to choosing it - please consider using Subversion for storing all interesting information. Thank you'''

[Matthew Good]

Replying to anonymous:

Trac looks awesome and we were so close to choosing it - please consider using Subversion for storing all interesting information. Thank you'''

Trac will probably support this at some point, but it is not a "high" priority right now.

2. We want a simple system with few dependencies and a simple backup procedure for all generated content. A separate database (with its dependencies) for issues and for the Wiki content unfortunately does not meet this need.

SQLite was chosen as the default database since it only requires the installation of a library. There's no setup involved since it's all handled internally by Trac. Storing the wiki and/or tickets in Subversion (or other VC software supported by Trac) does not eliminate Trac's need for a database, so that will always be a requirement. There are simple backup solutions for Trac. Please ask on the MailingList if you're interested.

[Russell Hind <rhind@…>]

Replying to mgood:

There are simple backup solutions for Trac. Please ask on the MailingList if you're interested.

Yes, even trac-admin hotsync works ok, but for our svn repositories (fsfs backend), we use rsync which provides very efficient incremental backups to remote locations easily. Using a database for the wiki and ticket information doesn't provide this possibility (well not for those of us who have no experience with databases/SQL).

Cheers

Russell

[Christian Boos]

Another long term idea.

[blais@…]

Every time I have to edit wiki pages through a web browser textarea, I wish for this feature to happen, so I can edit the wiki pages using Emacs. I really cannot understand why it was not designed this way in the first place… using SVN as a backend solves a number of problems, and only seems natural, given the nature of trac.

[gunther.seghers@…]

Can someone please provide a stepwise procedure on how to setup TRAC so that it allows to version wiki pages using SVN. The end-result should allow us to see, export all wiki pages belonging to a certain version label together with all other software artefacts

[Emmanuel Blot]

Replying to gunther.seghers@ipc.be:

Can someone please provide a stepwise procedure on how to setup TRAC so that it allows to version wiki pages using SVN. The end-result should allow us to see, export all wiki pages belonging to a certain version label together with all other software artefacts

Wiki pages are not stored in a SVN repository, so I'm afraid this feature is not available right now (and not really planned for being implemented within a short timeframe).

[anonymous]

I'd be very interested in this feature as well.

[anonymous]

I'm also quite astonished, that Subversion is NOT used for storing the changed wiki-pages. Is there any work in progress on that feature in the meantime? If there is a perspective, we might opt on using Trac, if not, we need to go on unfortunately because Postgres/SQLite/MySQL are not databases of our choice as Oracle or Informix are.

[Christian Boos]

Even if someday the Wiki pages are store in a versioncontrol backend, a database will always be needed, as there's much more persistent data in Trac than just the content of wiki pages. And most of these informations need to be readily available, so scanning through a vc backend is not an option.

OTOH, Oracle can eventually be supported one day, I think it's not more broken than MySQL ;-)

[Matthew Good]

Replying to anonymous:

Postgres/SQLite/MySQL are not databases of our choice as Oracle or Informix are.

I wouldn't think of SQLite as a database. The fact that it happens to support SQL is pretty much irrelevant from the end-user perspective. Learning to administer another database server like Postgres or MySQL obviously has some overhead, but SQLite is pretty much transparent. You're free not to use Trac, but I wouldn't place too much weight on the data format.

Replying to cboos:

OTOH, Oracle can eventually be supported one day, I think it's not more broken than MySQL ;-)

It's not broken in the same ways as MySQL, but Oracle has significant barriers to writing cross-db compatible SQL. Most notably it lacks LIMIT and OFFSET and the workarounds are quite ugly. SQLAlchemy will help, but I don't expect it to be easy.

[Harald]

Thanks for your and mgoods comment. I'm currently using Postgres for my Trac evaluation. Depending on the behavior during backup i might give Sqlite another try. Despite that, my main point was how to get the Wiki pages into a Subversion repo. I've read the whole discussion in the meantime and saw also the remarks about transient data being stored in the database as well. That would be ok. Again, the wiki-pages and attachments are my focus My question now: IS there any work in progress maybe basing on the partial implementation of PScholl as advocated in the article 'Advocating a Tighter Subversion Integration'? TIA Harald

Replying to cboos:

Even if someday the Wiki pages are store in a versioncontrol backend, a database will always be needed, as there's much more persistent data in Trac than just the content of wiki pages. And most of these informations need to be readily available, so scanning through a vc backend is not an option.

OTOH, Oracle can eventually be supported one day, I think it's not more broken than MySQL ;-)

[blais@…]

Harald: it's not work-in-progress, but a few months ago I figured out everything that had to be done for it, and started to write the code for it, and there is nothing that would prevent this from happening, it's just a matter of turning the crank: 1. isolate the DB access through a Python interface, 2. move the current code into one interface implementation, make sure everything still works (test), 3. implement another version that does the storage via subversion. The source code is already pretty much separated in a single module (apart from a few accesses to that DB table from another file).

I just haven't had the time to do it… this is really annoying me as well, I want to be able to edit the wiki pages from Emacs, grep them, process them with scripts, etc.

[Marc Fargas <telenieko@…>]

CC'ing myself, would be nice to see this working. And you can sum: all data that is, tickets, pages, etc ;)

[MBParker@…]

​http://sharpforge.org/p/SharpForge.aspx "is an open source, c#, dot net 2.0, easy to use project hosting web application. It's similar to SourceForge or CodePlex but for your own team or organisation."

SharpForge HAS a Subversion-based Wiki (though the wiki formatting may not be yet as powerful as Trac), plus "Work Item Tracking" like Trac, plus Forums, chat, and more, and HAS WYSIWYG data entry, and, designed recently (2006?), it is coded probably more cleanly in C# and DotNet 2.0. It is still in Beta, however, it works today - indeed the link above is apparently to the SharpForge project hosted in SharpForge itself. Moreover, its leading sponsor of SharpForge seems to be commercial hosting provider ​http://www.ProjXpert.com which uses SharpForge to host projects for folks commercially (and ​at low prices).

Overall, provided it actually does what it says (I haven't used it yet), and provided one is ok with hosting on DotNOT (which ​apparently can be done even in Linux via Mono), SharpForge seems to have more potential than any other web project hosting application I've heard of, no? For this reason, since about April, I've been planning on using SharpForge and ProjXpert (instead of Trac, Bugzilla, and the rest). I may be missing something, but SharpForge seems clearly worth considering - maybe something Trac wants to copy, or users want to choose instead.

[gunnar_thielebein@…]

i don't think this is a must have feature. I've gone through the trac mailinglist and the goal for futuredevelopment is to have a wider support of repositories, databases and so on. to save wiki in svn is not everyones approach.

For coding in java you already store the documentation of code in svn which is ok but how will you sort your code and your documentation if you also have the trac wiki stored there.

And if the trac wikiarticle also are in repo for what kind use? the oss crowed which makes an checkout doesn't need your articles, and don't forget that changesets want to be kept increment by codechange and not wikichanges.

[anonymous]

Replying to gunnar_thielebein@gmx.net:

i don't think this is a must have feature.

Ah, so you're not one of the people who wants it. That doesn't mean it's not important for others/

I've gone through the trac mailinglist and the goal for futuredevelopment is to have a wider support of repositories, databases and so on. to save wiki in svn is not everyones approach.

For coding in java you already store the documentation of code in svn which is ok but how will you sort your code and your documentation if you also have the trac wiki stored there.

And if the trac wikiarticle also are in repo for what kind use? the oss crowed which makes an checkout doesn't need your articles, and don't forget that changesets want to be kept increment by codechange and not wikichanges.

I for one would love to be able to keep documentation that's maintained through the wiki in proper version control - there are all kinds of reasons for it.

[Ivan G Shevchenko]

Trac data in SVN - very interesting proposal! Good arguments for this are here: TighterSubversionIntegration#Motivation

[Noah Kantrowitz]

Given the direction we are moving in w.r.t. supporting multiple VCSs, this doesn't seem likely to happen at any point without major changes to Trac. With the newhelp system being developed for 0.12, there will be an example module for displaying documention (or other wiki-like content) from Subversion directly. +1 to retarget to 0.12/newhelp.

[Christian Boos]

This ticket has nothing to do with the newhelp proposal (comment:34 and comment:35 side track on the topic of help, but that's not at all the main point of this ticket)..

Like explained in TighterSubversionIntegration, this is about storing all Trac data in a VCS system (wiki pages but also ticket data, milestones etc.).

One of the primary interest for such an approach is the possibility to distribute Trac data, when a DVCS is used for the backend storage (#1465).

Of course, this can't be done without deep changes, that's why it's 2.0 (experimental or alternative even).

[turbidostato <turbidostato@…>]

Replying to twenim@…:

Use Subversion for data repository like ​subwiki

I don't think this a proper description for the task (for a task, any task). It lacks a very important piece of information: What for?

As facts have demonstrated, simply "use Subversion for data repository" is meaningless: do you mean using Subversion as the wiki versioning back-end even if you are using a different SCM tool, like Git or Monotone? Don't think so.

So… what for?

This is a start:

• In order to gain the ability to distribute Trac data, when a DVCS is used for the backend storage.
• So wiki-based documentation is easily and firmly tied to SCM versioning: if I'm looking for docs relevant to the 0.10.x version, I'm not interested on, say, current version of the install wiki page which explains how to install 0.11, but some past (and probably branched) version that talked about 0.10.
• Remember the old motto: if you ever decide to go for such a feature, please. please, please don't try to (badly) reinvent the wheel and take advantage of the underlying tools you are already using (which probably means find an abstracted way to use the underlying SCM tool).

[yoheeb@…]

the sql-lite db file is just that. a file. backups are not all that hard. I get that you "want" to do it with the rsync command, however backing up a db file isn't that hard, and yes, it's binary, so technically, and incremental back-up will work fine.

aside from the "hot-sync" requirement, it's really not a burden.

I think the real solution, is to make a plug-in that will export the wiki to a repo. and automatically do so on changes to wiki pages, it's duplication of data, but that's the point of backups right?

as for editing the wiki with emacs, there is a VI plugin to do it via xmlrpc, I am sure emacs could be made to do the same, for example: ​http://www.meadowy.org/~gotoh/projects/trac-wiki/wiki is one for emacs.

[jens@…]

yoheeb, I assume by "the real solution" you mean "the real solution for backups". It's not a real solution if you consider any of the points turbidostato made. Which, incidentally, are the points I'm interested in.

[anonymous]

stick a fork in it - its dead. This is not going to happen, I've waited years - I don't care any more.

[Remy Blank]

Please don't change ticket fields without a good reason (and no, your leaving is not one of them).

[fcorreia@…]

(just listening… I'm really interested in this feature)

[bkuhn@…]

I'm going to make some effort on this feature. I have no idea if I'll be successful but get in touch if you are working on it.

[Christian Boos]

Replying to bkuhn@…:

I'm going to make some effort on this feature. I have no idea if I'll be successful but get in touch if you are working on it.

What a coincidence! Three days ago, while googling for some svn method, I stumbled upon Loblaw's Trac. Briefly looking at the differences, I noticed some work on the wiki store. As I went back there to find an appropriate page I link from here, I saw the same bkuhn name… so you probably don't need that link :-)

So yes, I think it would be quite interesting to see a patch summarizing your approach so far, along with a discussion of the problems encountered and what's eventually left to do.

[anonymous]

I think you just need a few features here:

0. Map a VCS url into the wiki url space. For e.g. wiki/CamelCase can be mapped to svn:/trunk/docs/CamelCase. We can have a special file like InterMapTxt to do this.

1. Ability to render a VCS file (e.g. .wiki or .html should be correctly rendered

2. Ability to edit VCS file. (Bonus points if you can make it WYSIWYG)

#0 is a totally new feature.

How hard can #1 be?

#2 means now you need to write to VCS which you don't seem to be doing currently.

If these three are implemented correctly, it will give 100% of what your user want. It will also work across all VCS as they all have APIs to checkin/checkout stuff.

Trac is a great project, I hope it does not die a sad death. Listen to your users!

[Gregory Hart <greg@…>]

Updated patch for 0.11.4 release

[Gregory Hart <greg@…>]

I updated pscholl's patch for the 0.11.4 release. I might be persuaded to create patches for other releases if someone is willing to test it.

[dfraser]

Replying to Gregory Hart <greg@…>:

I updated pscholl's patch for the 0.11.4 release. I might be persuaded to create patches for other releases if someone is willing to test it.

Got this error using this patch on 0.11.3:

    *    File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/web/main.py", line 444, in  _dispatch_request
      Code fragment:
       439. try:
       440. if not env and env_error:
       441. raise HTTPInternalError(env_error)
       442. try:
       443. dispatcher = RequestDispatcher(env)
       444. dispatcher.dispatch(req)
       445. except RequestDone:
       446. pass
       447. resp = req._response or []
       448.  
       449. except HTTPException, e:
      Local variables:
      Name	Value
      after 	[u' except RequestDone:', u' pass', u' resp = ...
      before 	[u' try:', u' if not env and env_error:', u' raise ...
      dispatcher 	<trac.web.main.RequestDispatcher object at 0x8c5fcac>
      e 	AttributeError("'SubversionNode' object has no attribute 'scoped_path'",)
      env 	<trac.env.Environment object at 0x8936b0c>
      env_error 	None
      exc_info 	(<type 'exceptions.AttributeError'>, AttributeError("'SubversionNode' ...
      filename 	'/home/davidf/work/upstream/agiletrac-tmp/trac/trac/web/main.py'
      frames 	[{'function': '_dispatch_request', 'lines_before': [u' try:', u' ...
      has_admin 	True
      line 	u' dispatcher.dispatch(req)'
      lineno 	443
      message 	u"AttributeError: 'SubversionNode' object has no attribute 'scoped_path'"
      req 	<Request "GET u'/wiki/Carnivore'">
      resp 	[]
      tb 	<traceback object at 0x8e90eb4>
      tb_hide 	None
      traceback 	u'Traceback (most recent call last):\n File ...
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/web/main.py", line 205, in dispatch
      Code fragment:
       200. req.args.get('__FORM_TOKEN') != req.form_token:
       201. raise HTTPBadRequest('Missing or invalid form token. '
       202. 'Do you have cookies enabled?')
       203.  
       204. # Process the request and render the template
       205. resp = chosen_handler.process_request(req)
       206. if resp:
       207. if len(resp) == 2: # Clearsilver
       208. chrome.populate_hdf(req)
       209. template, content_type = \
       210. self._post_process_request(req, *resp)
      Local variables:
      Name	Value
      chosen_handler 	<trac.wiki.web_ui.WikiModule object at 0x8c5fbac>
      chrome 	<trac.web.chrome.Chrome object at 0x8c5f98c>
      err 	(<type 'exceptions.AttributeError'>, AttributeError("'SubversionNode' ...
      handler 	<trac.wiki.web_ui.WikiModule object at 0x8c5fbac>
      req 	<Request "GET u'/wiki/Carnivore'">
      self 	<trac.web.main.RequestDispatcher object at 0x8c5fcac>
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/wiki/web_ui.py", line 118, in process_request
      Code fragment:
       113. old_version = req.args.get('old_version')
       114.  
       115. if pagename.endswith('/'):
       116. req.redirect(req.href.wiki(pagename.strip('/')))
       117.  
       118. page = WikiPage(self.env, pagename)
       119. versioned_page = WikiPage(self.env, pagename, version=version)
       120.  
       121. req.perm(page.resource).require('WIKI_VIEW')
       122. req.perm(versioned_page.resource).require('WIKI_VIEW')
       123.  
      Local variables:
      Name	Value
      action 	'view'
      old_version 	None
      pagename 	u'Carnivore'
      req 	<Request "GET u'/wiki/Carnivore'">
      self 	<trac.wiki.web_ui.WikiModule object at 0x8c5fbac>
      version 	None
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/wiki/model_svn.py", line 32, in __init__
      Code fragment:
        27. """Represents a wiki page (new or existing)."""
        28.  
        29. def __init__(self, env, name=None, version=None, db=None):
        30. self.env = env
        31. self.root = env.config.get( 'wiki', 'svn_root' )
        32. if not env.get_repository().get_node(self.root).kind in (Node.DIRECTORY, Node.FILE):
        33. raise TracError( "wiki root couldn't be found!" )
        34. if self.root[:-1] != '/': self.root += '/'
        35. if isinstance(name, Resource):
        36. self.resource = name
        37. name = self.resource.id
      Local variables:
      Name	Value
      db 	None
      env 	<trac.env.Environment object at 0x8936b0c>
      name 	u'Carnivore'
      self 	<trac.wiki.model_svn.WikiPage object at 0x8c5fcec>
      version 	None
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/cache.py", line 233, in get_node
      Code fragment:
       228. finally:
       229. # 3. restore permission checking (after 1.)
       230. self.repos.authz = authz
       231.  
       232. def get_node(self, path, rev=None):
       233. return self.repos.get_node(path, rev)
       234.  
       235. def _get_node_revs(self, path, last=None, first=None):
       236. """Return the revisions affecting `path` between `first` and `last`
       237. revisions.
       238. """
      Local variables:
      Name	Value
      path 	u'/wiki/'
      rev 	None
      self 	<trac.versioncontrol.cache.CachedRepository object at 0x8e978cc>
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/svn_fs.py", line 434, in get_node
      Code fragment:
       429. if path and path[-1] == '/':
       430. path = path[:-1]
       431.  
       432. rev = self.normalize_rev(rev) or self.youngest_rev
       433.  
       434. return SubversionNode(path, rev, self, self.pool)
       435.  
       436. def _get_node_revs(self, path, last=None, first=None):
       437. """Return the revisions affecting `path` between `first` and `last`
       438. revs. If `first` is not given, it goes down to the revision in which
       439. the branch was created.
      Local variables:
      Name	Value
      path 	u'/wiki'
      rev 	1812
      self 	<trac.versioncontrol.svn_fs.SubversionRepository object at 0x8c5fc8c>
    * File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/svn_fs.py", line 672, in __init__
      Code fragment:
       667. else:
       668. self.root = fs.revision_root(self.fs_ptr, rev, self.pool())
       669. node_type = fs.check_path(self.root, self._scoped_path_utf8, pool)
       670. if node_type == core.svn_node_none:
       671. self.created_rev = 0
       672. self.created_path = self.scoped_path
       673. self.rev = self.created_rev
       674. node_type = core.svn_node_file
       675. elif not node_type in _kindmap:
       676. raise NoSuchNode(path, rev)
       677. cp_utf8 = fs.node_created_path(self.root, self._scoped_path_utf8, pool)
      Local variables:
      Name	Value
      node_type 	0
      parent_root 	None
      path 	u'/wiki'
      pool 	<libsvn.core.apr_pool_t; proxy of <Swig Object of type 'apr_pool_t *' at ...
      repos 	<trac.versioncontrol.svn_fs.SubversionRepository object at 0x8c5fc8c>
      rev 	1812
      self 	<trac.versioncontrol.svn_fs.SubversionNode object at 0x8c4fe2c>

File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/web/main.py", line 444, in _dispatch_request
  dispatcher.dispatch(req)
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/web/main.py", line 205, in dispatch
  resp = chosen_handler.process_request(req)
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/wiki/web_ui.py", line 118, in process_request
  page = WikiPage(self.env, pagename)
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/wiki/model_svn.py", line 32, in __init__
  if not env.get_repository().get_node(self.root).kind in (Node.DIRECTORY, Node.FILE):
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/cache.py", line 233, in get_node
  return self.repos.get_node(path, rev)
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/svn_fs.py", line 434, in get_node
  return SubversionNode(path, rev, self, self.pool)
File "/home/davidf/work/upstream/agiletrac-tmp/trac/trac/versioncontrol/svn_fs.py", line 672, in __init__
  self.created_path = self.scoped_path

[ukubuku@…]

Guys, it is the perfect Trac patch, but can this be a plugin? I run multiple Trac environments and would like to have such functionality only for one of them.

[fyodor@…]

You might want to consider using ​Artifacts format for Issues - in that case you will get a good offline client.

[Christian Boos]

#9063 was closed as duplicate.

[team@…]

Anybody tested this patch? Does it work? I can't make it running, too many errors in different places.

When I'm trying to view a wiki page I'm getting this message:

Genshi UnicodeDecodeError error while rendering template (unknown template location)

When I'm trying to make changes to a page, I'm getting this:

AttributeError: 'SubversionNode' object has no attribute 'scoped_path'

File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/web/main.py", line 435, in _dispatch_request
File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/web/main.py", line 205, in dispatch
File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/wiki/web_ui.py", line 143, in process_request
File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/wiki/web_ui.py", line 278, in _do_save
File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/wiki/model_svn.py", line 94, in save
File "/home/technoparkcorp/lib/python2.5/Trac-0.11.4-py2.5.egg/trac/versioncontrol/svn_fs.py", line 782, in set_content

[anonymous]

For anyone that is interested, the ​TracDocsPlugin creates a "Docs" tab which allows editing and viewing of wiki documentation stored in the Subversion repository.

[Christian Boos]

Milestone 2.0 deleted

[Christian Boos]

See also TracDev/Proposals/AdvancedWikiOperations#Diff

[bkuhn@…]

Hack patch against 0.11.7, based on previous ones, to store your Wiki in svn.

[bkuhn@…]

It looks like cboos has upgraded the priority of this ticket and we may get this feature in the main version of Trac soon. But, in the meantime, I've attached this patch​, a modified version of Gregory Hart's patch. IWFM against 0.11.7 and perhaps will fix the problem dfraser mentioned. I've been using the attached patch in production on a 0.11.7 install with no problems.

I hereby license any copyright interests I have in this patch under the license of Trac itself as described in the COPYING file of the 0.11.7 release.

[Christian Boos]

Thanks! That's a great start.

For trunk, the permission checks need to be adapted to the TracFineGrainedPermissions (as the svn_authz stuff has been integrated as one policy among others in this more general permission framework), and … as usual, a bit of clean-up according to our coding style. Also, a possibility to choose between the storage backend would be nice, so that the two modes could coexist in the same codebase (maybe through an .ini option?). Finally, a contrib/ script for migrating (db → svn) would be great.

[Remy Blank]

I would also like this feature to make it into core. One concern, though: is Node.set_content() the right interface for modifying the repository? This means only a single file can be modified per commit. How about allowing to modify a list of nodes in a single operation?

[Christian Boos]

We could imagine using a similar mechanism that the one we have for db transactions… Something like: with repos.commit(author, message) as tx: and have the outer context do the actual commit with all the operations recorded in tx. The tx (RepositoryTransaction type) would have operations like add, remove, set_content, …

This way, we could have a Node.set_content with an interface similar to the proposed on ( def set_content(self,content,commitmsg="changed by trac",uname=""): for reminder), implemented in terms of tx.set_content.

[anonymous]

Are there any new regarding this issue

[Christian Boos]

Sort of: xmas holidays are getting closer and I'll find some time for this, part of some bigger rework of the wiki. So there should be some real news on this topic till the end of the year…

[Christian Boos]

I've started to work on this last week. See the implementation plan in TracDev/Proposals/WikiStorage.

[dkg@…]

Any more word on this? I'm interested in it because i want annotation support for trac wiki pages, and #5821 suggests this is the route to get there. I'd prefer git as a backend over subversion, if possible.

[Oleg Tsarev <oleg@…>]

Any updates?