I'm completely new to the Trac development community, although I've been a Trac user for a few years. I'm now using Trac as part of a project to adapt various excellent hacker tools (Trac in particular) for use in a small office environment for non-hackers.
I'm a huge fan of DAV storage, which allows those of us prefer to manipulate files directly using SVN, but allows for other interfaces.
For this reason, I currently use for our Wiki a dead project called SubWiki (http://subwiki.tigris.org/). I am now moving our infrastructure over to Trac, and don't want to lose the versatility that a DAV-stored Wiki gives us; I have various other subsystems that rely on it.
I am beginning to implement in Trac optional Wiki storage engines, so that in addition to storing the Wiki in the database, it can also instead be stored in an SVN repository via DAV.
I don't know if this idea is of interest to the Trac community or not, but I thought I'd post here to let you know that I've begun this work. If folks here think it is a good, bad and/or ugly idea, please let me know. As I begin the work, I'm going to just carry a patch of my own against your trunk, and will post here about any progress that I make if it is of interest to you.
Thanks for any input, thoughts, warnings, etc. that you might have. --
> I'm completely new to the Trac development community, although I've been > a Trac user for a few years. I'm now using Trac as part of a project to > adapt various excellent hacker tools (Trac in particular) for use in a > small office environment for non-hackers.
> I'm a huge fan of DAV storage, which allows those of us prefer to > manipulate files directly using SVN, but allows for other interfaces.
> For this reason, I currently use for our Wiki a dead project called > SubWiki (http://subwiki.tigris.org/). I am now moving our > infrastructure over to Trac, and don't want to lose the versatility that > a DAV-stored Wiki gives us; I have various other subsystems that rely on > it.
> I am beginning to implement in Trac optional Wiki storage engines, so > that in addition to storing the Wiki in the database, it can also > instead be stored in an SVN repository via DAV.
> I don't know if this idea is of interest to the Trac community or not, > but I thought I'd post here to let you know that I've begun this work. > If folks here think it is a good, bad and/or ugly idea, please let me > know. As I begin the work, I'm going to just carry a patch of my own > against your trunk, and will post here about any progress that I make if > it is of interest to you.
There are definitely others interested in this feature. Someone was hacking on it during the sprints at last years PyCon, but didn't get too far.
I highly suggest you maintain a compatible interface with the trac.wiki API and trac.wiki.model.WikiPage in particular, if at all possible.
> I'm completely new to the Trac development community, although I've been
> a Trac user for a few years. I'm now using Trac as part of a project to
> adapt various excellent hacker tools (Trac in particular) for use in a
> small office environment for non-hackers.
> I'm a huge fan of DAV storage, which allows those of us prefer to
> manipulate files directly using SVN, but allows for other interfaces.
> For this reason, I currently use for our Wiki a dead project called
> SubWiki (http://subwiki.tigris.org/). I am now moving our
> infrastructure over to Trac, and don't want to lose the versatility that
> a DAV-stored Wiki gives us; I have various other subsystems that rely on
> it.
> I am beginning to implement in Trac optional Wiki storage engines, so
> that in addition to storing the Wiki in the database, it can also
> instead be stored in an SVN repository via DAV.
> I don't know if this idea is of interest to the Trac community or not,
> but I thought I'd post here to let you know that I've begun this work.
> If folks here think it is a good, bad and/or ugly idea, please let me
> know. As I begin the work, I'm going to just carry a patch of my own
> against your trunk, and will post here about any progress that I make if
> it is of interest to you.
> Thanks for any input, thoughts, warnings, etc. that you might have.
> --
Alec Thomas wrote: > On 22/02/2008, Bradley M. Kuhn <bk...@softwarefreedom.org> wrote:
>> I'm completely new to the Trac development community, although I've been >> a Trac user for a few years. I'm now using Trac as part of a project to >> adapt various excellent hacker tools (Trac in particular) for use in a >> small office environment for non-hackers.
>> I'm a huge fan of DAV storage, which allows those of us prefer to >> manipulate files directly using SVN, but allows for other interfaces.
>> For this reason, I currently use for our Wiki a dead project called >> SubWiki (http://subwiki.tigris.org/). I am now moving our >> infrastructure over to Trac, and don't want to lose the versatility that >> a DAV-stored Wiki gives us; I have various other subsystems that rely on >> it.
>> I am beginning to implement in Trac optional Wiki storage engines, so >> that in addition to storing the Wiki in the database, it can also >> instead be stored in an SVN repository via DAV.
>> I don't know if this idea is of interest to the Trac community or not, >> but I thought I'd post here to let you know that I've begun this work. >> If folks here think it is a good, bad and/or ugly idea, please let me >> know. As I begin the work, I'm going to just carry a patch of my own >> against your trunk, and will post here about any progress that I make if >> it is of interest to you.
> There are definitely others interested in this feature. Someone was > hacking on it during the sprints at last years PyCon, but didn't get too > far.
> I highly suggest you maintain a compatible interface with the trac.wiki > API and trac.wiki.model.WikiPage in particular, if at all possible.
I wouldn't recommend that approach though, as I think the changes are a bit too invasive. The wiki/web_ui.py code should ideally be unchanged and the wiki/model.py should instead get one more layer, to delegate the storage to either a db backend or a vc backend. Ideally, that vc backend could be any vc, i.e. you should not make direct calls to the svn api. For that, the versioncontrol api should be extended to have some "commit" methods - don't forget that besides DAV, you would still occasionally want to edit your pages from the web interface!
