Edgewall Software
Modify

Opened 20 years ago

Last modified 9 years ago

#1132 new enhancement

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

Reported by: twenim@… Owned by:
Priority: normal Milestone: next-major-releases
Component: general Version: none
Severity: critical Keywords: objectstore
Cc: fjh-mailbox-38@…, danarmak@…, norbert.Klamann@…, jens@…, MBParker@…, florian.burka@…, telenieko@…, davidf@…, gunnar_thielebein@…, Shevchenko, linuxadmin@…, bkuhn@…, greg@…, team@…, eikeon@…, leho@…, itamarost@…, dkg@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Use Subversion for data repository like subwiki

Attachments (2)

svn-wiki-backend-patch-0.11.4.patch (15.1 KB ) - added by Gregory Hart <greg@…> 15 years ago.
Updated patch for 0.11.4 release
store-wiki-in-svn-for-0.11.7.patch (15.0 KB ) - added by bkuhn@… 14 years ago.
Hack patch against 0.11.7, based on previous ones, to store your Wiki in svn.

Download all attachments as: .zip

Change History (75)

comment:1 by Christopher Lenz, 20 years ago

Milestone: 1.0
Priority: highnormal

comment:2 by florian.burka@…, 19 years ago

Keywords: subversion added

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

comment:3 by anonymous, 19 years ago

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

comment:4 by dserodio@…, 19 years ago

Cc: dserodio@… added

comment:5 by anonymous, 19 years ago

Cc: rhind@… added

comment:6 by anonymous, 19 years ago

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

comment:7 by Fergus Henderson <fjh-mailbox-38@…>, 19 years ago

Cc: fjh-mailbox-38@… added

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

comment:8 by anonymous, 19 years ago

Cc: danarmak@… added

comment:9 by Christian Boos, 19 years ago

Keywords: objectstore added; subversion removed
Owner: changed from Jonas Borgström to Christian Boos

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

comment:10 by Emmanuel Blot, 19 years ago

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

comment:11 by Christian Boos, 19 years ago

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.

comment:12 by (none), 19 years ago

Cc: norbert.Klamann@… added

comment:13 by MBParker@…, 18 years ago

Cc: jens@… MBParker@… added
Component: wikigeneral
Summary: Use Subversion for data repositoryUse Subversion (or the source repository) for Trac's data as well

(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

comment:14 by Russell Hind <rhind@…>, 18 years ago

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)

comment:15 by Russell Hind <rhind@…>, 18 years ago

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

Cheers

Russell

comment:16 by anonymous, 18 years ago

Cc: florian.burka@… added

comment:17 by anonymous, 18 years ago

Cc: trac@… added

comment:18 by anonymous, 18 years ago

Priority: normalhigh

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'''

in reply to:  18 ; comment:19 by Matthew Good, 18 years ago

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.

in reply to:  19 comment:20 by Russell Hind <rhind@…>, 18 years ago

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

comment:21 by Christian Boos, 18 years ago

Milestone: 2.0

Another long term idea.

comment:22 by blais@…, 18 years ago

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.

comment:23 by gunther.seghers@…, 18 years ago

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

in reply to:  23 comment:24 by Emmanuel Blot, 18 years ago

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).

comment:25 by anonymous, 18 years ago

Cc: remy.blank@… added

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

comment:26 by anonymous, 18 years ago

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.

comment:27 by Christian Boos, 18 years ago

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 ;-)

in reply to:  26 comment:28 by Matthew Good, 18 years ago

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.

in reply to:  27 comment:29 by Harald, 18 years ago

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 ;-)

comment:30 by blais@…, 18 years ago

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.

comment:31 by Marc Fargas <telenieko@…>, 17 years ago

Cc: telenieko@… added

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

comment:32 by anonymous, 17 years ago

Cc: davidf@… added

comment:33 by MBParker@…, 17 years ago

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.

comment:34 by gunnar_thielebein@…, 17 years ago

Cc: gunnar_thielebein@… added

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.

in reply to:  34 comment:35 by anonymous, 17 years ago

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.

comment:36 by Ivan G Shevchenko, 16 years ago

Cc: Shevchenko added

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

comment:37 by Ivan G Shevchenko <linuxadmin@…>, 16 years ago

Cc: linuxadmin@… added

comment:38 by rhind@…, 16 years ago

Cc: rhind@… removed

comment:39 by Noah Kantrowitz, 16 years ago

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.

comment:40 by Christian Boos, 16 years ago

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).

comment:41 by trac@…, 16 years ago

Cc: trac@… removed

in reply to:  description comment:42 by turbidostato <turbidostato@…>, 16 years ago

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).

comment:43 by yoheeb@…, 16 years ago

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.

comment:44 by jens@…, 16 years ago

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.

comment:45 by anonymous, 16 years ago

Milestone: 2.0not applicable
Priority: highlowest
Severity: normaltrivial

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

comment:46 by Remy Blank, 16 years ago

Cc: remy.blank@… removed
Milestone: not applicable2.0
Priority: lowestnormal
Severity: trivialnormal

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

comment:47 by fcorreia@…, 16 years ago

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

comment:48 by bkuhn@…, 16 years ago

Cc: bkuhn@… added

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.

in reply to:  48 comment:49 by Christian Boos, 16 years ago

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.

comment:50 by anonymous, 15 years ago

I think you just need a few features here:

  1. 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
  1. 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!

by Gregory Hart <greg@…>, 15 years ago

Updated patch for 0.11.4 release

comment:51 by Gregory Hart <greg@…>, 15 years ago

Cc: greg@… added

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.

in reply to:  51 comment:52 by dfraser, 15 years ago

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

comment:53 by ukubuku@…, 15 years ago

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.

comment:54 by fyodor@…, 15 years ago

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

comment:55 by Christian Boos, 15 years ago

Cc: team@… added

#9063 was closed as duplicate.

comment:56 by team@…, 15 years ago

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

comment:57 by anonymous, 14 years ago

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

comment:58 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:59 by Daniel Krech <eikeon@…>, 14 years ago

Cc: eikeon@… added

comment:60 by Christian Boos, 14 years ago

Milestone: triagingnext-major-0.1X
Severity: normalcritical

by bkuhn@…, 14 years ago

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

in reply to:  51 comment:61 by bkuhn@…, 14 years ago

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.

comment:62 by Christian Boos, 14 years ago

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.

comment:63 by Remy Blank, 14 years ago

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?

comment:64 by Christian Boos, 14 years ago

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.

comment:65 by lkraav <leho@…>, 14 years ago

Cc: leho@… added

comment:66 by Itamar Oren, 14 years ago

Cc: itamarost@… added

comment:67 by anonymous, 14 years ago

Are there any new regarding this issue

comment:68 by Christian Boos, 14 years ago

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…

comment:69 by Christian Boos, 14 years ago

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

comment:70 by dkg@…, 11 years ago

Cc: dkg@… added

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.

comment:71 by Oleg Tsarev <oleg@…>, 11 years ago

Any updates?

comment:72 by dserodio@…, 11 years ago

Cc: dserodio@… removed

comment:73 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.