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: | 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)
Change History (75)
comment:1 by , 20 years ago
Milestone: | 1.0 |
---|---|
Priority: | high → normal |
comment:2 by , 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 , 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
- Deletion of pages.
- Add the TimeLineEventProvider and ISearchProvider.
- Testing the authz support.
comment:4 by , 19 years ago
Cc: | added |
---|
comment:5 by , 19 years ago
Cc: | added |
---|
comment:6 by , 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 , 19 years ago
Cc: | added |
---|
My company is currently using Twiki, but we're planning to switch over to Trac if/when this is supported.
comment:8 by , 19 years ago
Cc: | added |
---|
comment:9 by , 19 years ago
Keywords: | objectstore added; subversion removed |
---|---|
Owner: | changed from | to
I'm going to update the TracObjectModelProposal with an API for object storage an revisioning.
comment:10 by , 19 years ago
A question about implementing an SVN backend: what about the search feature ?
comment:11 by , 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 , 19 years ago
Cc: | added |
---|
comment:13 by , 18 years ago
Cc: | added |
---|---|
Component: | wiki → general |
Summary: | Use Subversion for data repository → Use 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 , 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 , 18 years ago
(Sorry, didn't realise I'd already posted part of this above)
Cheers
Russell
comment:16 by , 18 years ago
Cc: | added |
---|
comment:17 by , 18 years ago
Cc: | added |
---|
follow-up: 19 comment:18 by , 18 years ago
Priority: | normal → high |
---|
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'''
follow-up: 20 comment:19 by , 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.
comment:20 by , 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:22 by , 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.
follow-up: 24 comment:23 by , 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
comment:24 by , 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).
follow-up: 28 comment:26 by , 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.
follow-up: 29 comment:27 by , 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 ;-)
comment:28 by , 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.
comment:29 by , 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 , 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 , 17 years ago
Cc: | 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 , 17 years ago
Cc: | added |
---|
comment:33 by , 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.
follow-up: 35 comment:34 by , 17 years ago
Cc: | 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.
comment:35 by , 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 , 16 years ago
Cc: | added |
---|
Trac data in SVN - very interesting proposal! Good arguments for this are here: TighterSubversionIntegration#Motivation
comment:37 by , 16 years ago
Cc: | added |
---|
comment:38 by , 16 years ago
Cc: | removed |
---|
comment:39 by , 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 , 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 , 16 years ago
Cc: | removed |
---|
comment:42 by , 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 , 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 , 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 , 16 years ago
Milestone: | 2.0 → not applicable |
---|---|
Priority: | high → lowest |
Severity: | normal → trivial |
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 , 16 years ago
Cc: | removed |
---|---|
Milestone: | not applicable → 2.0 |
Priority: | lowest → normal |
Severity: | trivial → normal |
Please don't change ticket fields without a good reason (and no, your leaving is not one of them).
follow-up: 49 comment:48 by , 16 years ago
Cc: | 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.
comment:49 by , 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 , 15 years ago
I think you just need a few features here:
- 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.
- Ability to render a VCS file (e.g. .wiki or .html should be correctly rendered
- 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 , 15 years ago
Attachment: | svn-wiki-backend-patch-0.11.4.patch added |
---|
Updated patch for 0.11.4 release
follow-ups: 52 61 comment:51 by , 15 years ago
Cc: | 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.
comment:52 by , 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 , 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 , 15 years ago
You might want to consider using Artifacts format for Issues - in that case you will get a good offline client.
comment:56 by , 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 , 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:59 by , 14 years ago
Cc: | added |
---|
comment:60 by , 14 years ago
Milestone: | triaging → next-major-0.1X |
---|---|
Severity: | normal → critical |
by , 14 years ago
Attachment: | store-wiki-in-svn-for-0.11.7.patch added |
---|
Hack patch against 0.11.7, based on previous ones, to store your Wiki in svn.
comment:61 by , 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 , 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 , 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 , 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 , 14 years ago
Cc: | added |
---|
comment:66 by , 14 years ago
Cc: | added |
---|
comment:68 by , 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 , 14 years ago
I've started to work on this last week. See the implementation plan in TracDev/Proposals/WikiStorage.
comment:70 by , 11 years ago
Cc: | 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:72 by , 11 years ago
Cc: | removed |
---|
comment:73 by , 9 years ago
Owner: | removed |
---|
See TighterSubversionIntegration.