Mailing List Archive

Alik Eliashberg wrote:

>With current use of SQLite, having a dynamic wiki (one that changes
>frequently) becomes very space-expensive - every time a document is changed,
>it is completely duplicated in another entry of 'wiki' table.
>
I do agree on the first statement: SQLlite stores all versions of each
Wiki page, with no 'diff-like' system, which can make Wiki quite large
... for very large Wikis.
I'm not sure storing it inside a Subversion repository is a better
approach, however.
However, an improvement could be to store the last version of a Wiki
page as plain text, and store previous releases as reverse diffs, for
example. Older page are rarely browsed, and diff computation time could
be acceptable for those pages.

I read that Trac future features include support for alternative source
control software. Adding a dependency on a specific one should be avoided.

>Second (and unrelated) question is why does Trac use SQLite for its internal
>storage?
>
I guess that some clues would be:

* SQLlite is ... lite and very fast. You cannot get that speed with a
BDB database. Do no forget Trac Wiki pages are generated on-the-fly.
* BDB does not support SQL interface. Which means another layer should
be added to translate SQL statement into BDB requests
* SQLlite provides all the features Trac needs. BDB would be an
overkiller for this kind of application
* It is not true anymore that Subversion uses BDB: it can use BDB, but
it also can use its proprietary repository backend (FSFS, starting
release 1.1). Trac should not add a dependency onto BDB if one uses
Subversion FSFS backend
* ?

Regards,
Emmanuel.

But it would be really nice if trac used subversion for the wiki pages.
Then one could edit them in a normal editor.



/Toni

-----Original Message-----
From: trac-bounces@lists.edgewall.com
[mailto:trac-bounces@lists.edgewall.com]On Behalf Of Emmanuel Blot
Sent: Sunday, August 15, 2004 1:46 AM
To: trac@lists.edgewall.com
Subject: Re: [Trac] Why does Trac use SQLite for Wiki?


Alik Eliashberg wrote:

>With current use of SQLite, having a dynamic wiki (one that changes
>frequently) becomes very space-expensive - every time a document is changed,
>it is completely duplicated in another entry of 'wiki' table.
>
I do agree on the first statement: SQLlite stores all versions of each
Wiki page, with no 'diff-like' system, which can make Wiki quite large
... for very large Wikis.
I'm not sure storing it inside a Subversion repository is a better
approach, however.
However, an improvement could be to store the last version of a Wiki
page as plain text, and store previous releases as reverse diffs, for
example. Older page are rarely browsed, and diff computation time could
be acceptable for those pages.

I read that Trac future features include support for alternative source
control software. Adding a dependency on a specific one should be avoided.

>Second (and unrelated) question is why does Trac use SQLite for its internal
>storage?
>
I guess that some clues would be:

* SQLlite is ... lite and very fast. You cannot get that speed with a
BDB database. Do no forget Trac Wiki pages are generated on-the-fly.
* BDB does not support SQL interface. Which means another layer should
be added to translate SQL statement into BDB requests
* SQLlite provides all the features Trac needs. BDB would be an
overkiller for this kind of application
* It is not true anymore that Subversion uses BDB: it can use BDB, but
it also can use its proprietary repository backend (FSFS, starting
release 1.1). Trac should not add a dependency onto BDB if one uses
Subversion FSFS backend
* ?

Regards,
Emmanuel.

_______________________________________________
Trac mailing list
Trac@lists.edgewall.com
http://lists.edgewall.com/mailman/listinfo/trac

--- Emmanuel Blot <eblotml@free.fr> wrote:
> I do agree on the first statement: SQLlite stores all versions of each
> Wiki page, with no 'diff-like' system, which can make Wiki quite large
> ... for very large Wikis.
> I'm not sure storing it inside a Subversion repository is a better
> approach, however.
> However, an improvement could be to store the last version of a Wiki
> page as plain text, and store previous releases as reverse diffs, for
> example. Older page are rarely browsed, and diff computation time could
> be acceptable for those pages.
This is essentially how version control system works - so effectively Trac
would have to implement a version control system. It is not rocket science to
do, but is that within the scope of the project?

> I read that Trac future features include support for alternative source
> control software. Adding a dependency on a specific one should be avoided.
Well, that means that Trac would have to develop some sort of a
"backend-independent" version control interface. That means that it can use
whatever the current version control system for its wiki.

Another nice benefit for having an external version-control system used for
wiki backend would be the ability to add/remove/manage wiki pages outside of
Trac. For example, through some sort of a gateway that updates FAQ wiki
nightly based on some criteria (like new entries in the internal KB).
This certainly can be achieved through extending trac-admin as well, but
again, it seems to me to be outside of the scope of the project.

Alik




__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

>Another nice benefit for having an external version-control system used for
>wiki backend would be the ability to add/remove/manage wiki pages outside of
>Trac.
>

Could be dangerous: how do you manage cases where a Wiki page is removed
from outside Trac, but non-Wiki page in Trac (like the issue tracker)
points onto this page ?
Editing Wiki pages with an external editor... yes, but will it still be
a *Wiki* in this case ?

--- Emmanuel Blot <eblotml@free.fr> wrote:
> >Another nice benefit for having an external version-control system used
> > for wiki backend would be the ability to add/remove/manage wiki pages
> >outside of Trac.
> Could be dangerous: how do you manage cases where a Wiki page is removed
> from outside Trac, but non-Wiki page in Trac (like the issue tracker)
> points onto this page ?
Why would that be a problem? So you will end up with a dead link.
In general, flexibility comes at a cost - the proverbial "rope to hang
yourself." To take the example to the extreme, what prevents me from going
into trac's project directory and deleting 'trac.db' file...

> Editing Wiki pages with an external editor... yes, but will it still be
> a *Wiki* in this case ?
Why wouldn't it be? It can still have web interface. For example, it might be
easier to use your favorite editor to create a base page and then use web
front end to do updates and community-changes.

Alik





__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

>
> Could be dangerous: how do you manage cases where a Wiki page
> is removed
> from outside Trac, but non-Wiki page in Trac (like the issue tracker)
> points onto this page ?
> Editing Wiki pages with an external editor... yes, but will
> it still be
> a *Wiki* in this case ?
>

I dont see the difference from using trac-admin to delete and load pages.
But the positive benefits for using subversion is that ppl that install
trac are familiar with how subversion works so it one less thing to learn.
You also get all extra benefits that version control has merging/diff etc.
As admin this would be quite nice to be able to do outside of trac-admin
and with a familiar interface.

Alik Eliashberg wrote:

> Hello,
>
> I just started looking at Trac and it looks very interesting.
>>From playing with it (for a whole of a day), I have a quick "design" question
> - why does Trac use SQLite to store version information of the Wiki? It would
> seem that since Trac is tightly integrated with Subversion, it should us it
> for Wiki as well (e.g. create a separate subversion repository somewhere in
> the trac project directory).
>
Trac is even more tightly integrated with sql(ite). The timeline uses a
simple sql query to collect recent changes from all different trac
modules and the report system is simply built around sql queries. The
same goes for searching...

> With current use of SQLite, having a dynamic wiki (one that changes
> frequently) becomes very space-expensive - every time a document is changed,
> it is completely duplicated in another entry of 'wiki' table. For example, if
> you assume that a discussion is happening over wiki, with every person adding
> a roughly equally sized chunks of text, the space use becomes O(n!), instead
> of O(n) with a version control system that only saves the differences.
>
That's true but with the cheap disc drives of today it's quite hard to
motivate using a much more complicated approach just to save a few
kilobytes of disc space.

> Second (and unrelated) question is why does Trac use SQLite for its internal
> storage? Given that it is closely tied to Subversion, and subversion uses
> BDB, wouldn't it make sense to build Trac on top of BDB as well - that would
> save the administrator need to learn operation, backup, and recovery of two
> different database systems. Python bindings for DB4 do exist
> (pybsddb.sourceforge.net) (although I never used them) and it would appear
> that all functionality of SQLite is supported by DB4. What's the catch?
>
What? Berkeley db is just a key-value database with transaction support.
It would be extremely difficult to replace all sql code in Trac with
a bdb backend.

/ Jonas
--
Jonas Borgstr?m | Edgewall Software
jonas@edgewall.com | Professional GNU/Linux & Open Source Consulting.
| http://www.edgewall.com/

Well, that is the power of trac, linking from other non-wiki pages to
wiki pages.

This model also encourage us to integrate the project documentation in
the wiki. This way, commit log and tickets could refer to specifications
or technical guides when needed. However, project documentation is an
integral part of the project, and should not be limited to be browsed
using trac. Using a wiki processor like rst may help. So if we produce
wiki pages in rst that should be integral part of the project, that
would be nice to have it in the project repository.

Currently, we are thinking about a regular dump of these wiki pages to
the repository, which will create redundancy of course. Having the wiki
integrated with the versioning system would be really nice, and have a
lot of sense. What else in wiki pages than related project information ?
Why not having all these information in the project repository itself ?

To answer your question, it will not be only a wiki, if you just want a
wiki, take a standalone one not trac. This is only my honest opinion, no
flame here, and congratulation, trac is a great product. We have started
using it for our open-source projects and we are planning to use for our
internal projects too.

Denis Gervalle
SOFTEC sa
http://www.softec.st

Emmanuel Blot wrote:

>
>> Another nice benefit for having an external version-control system
>> used for
>> wiki backend would be the ability to add/remove/manage wiki pages
>> outside of
>> Trac.
>
>
> Could be dangerous: how do you manage cases where a Wiki page is
> removed from outside Trac, but non-Wiki page in Trac (like the issue
> tracker) points onto this page ?
> Editing Wiki pages with an external editor... yes, but will it still
> be a *Wiki* in this case ?
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

Hi,

> I read that Trac future features include support for alternative
> source control software. Adding a dependency on a specific one should
> be avoided.

I would even vote for a tighter integration of trac and subversion (e.g.
a post-2010 issue to have subversion and trac merged together :-). The
reason for my opinion is, that having this design goal is a nice
developer task, but it only cuts trac down in possible features. If you
try to find a common interface for different version control software
you can necessarily only support those feautres available in all
versioning software. You will loose all features available through
subversion, esp. unique revision numbers, changesets (and perhaps custom
properties)

There are a lot of tools available that integrate with other versioning
tools like bugzilla, I think, there is even a CVSTrac software
available. There is no need to gain some importance in using trac with
cvs e.g.

Trac looks very promising and has the power to build an high grade
integrated IssueTracking, Wiki, ProjectManagment, Documentation, and so
forth tool. Don't cut features only because you want to support older
versioning software, that does not provide the necessary infrastructure.

Just my 2 cents.

For the original discussion, about why use SQL for the wiki, I asked
myself the same question, when I first read about Trac. Another writer
also stated that it would be wonderful, if some project documentation
(now stored in the wiki) could be part of the svn repository itself.
This looks like a task for an InterWiki. Having different wiki store
backends that can reside in different places come into my mind.

For the WIKI and SQL issue: There was some discussion to add an SQL
backend to subversion as a 2.0 feature. Don't know wether this is still
true. But perhaps trac can use this backend to store changing wiki pages
within a SQL database without loosing the possibility of querying the
database itself.

After I have converted our VSS repository to subversion, I will also
start using TRAC. For what I have seen right now, it is a good peace of
software.

Best regards
Dirk

As a work around what about a new macro

[[Include(File or Wiki)FromSVN('/path/inside/subversion') ]]

work for wiki page, but also for included some source code (ex sample or
contrib) , doc, etc.

Francois Harvey
SecuriWeb inc.

trac@nogga.de wrote:

> Hi,
>
>> I read that Trac future features include support for alternative
>> source control software. Adding a dependency on a specific one should
>> be avoided.
>
>
> I would even vote for a tighter integration of trac and subversion
> (e.g. a post-2010 issue to have subversion and trac merged together
> :-). The reason for my opinion is, that having this design goal is a
> nice developer task, but it only cuts trac down in possible features.
> If you try to find a common interface for different version control
> software you can necessarily only support those feautres available in
> all versioning software. You will loose all features available through
> subversion, esp. unique revision numbers, changesets (and perhaps
> custom properties)
>
> There are a lot of tools available that integrate with other
> versioning tools like bugzilla, I think, there is even a CVSTrac
> software available. There is no need to gain some importance in using
> trac with cvs e.g.
>
> Trac looks very promising and has the power to build an high grade
> integrated IssueTracking, Wiki, ProjectManagment, Documentation, and
> so forth tool. Don't cut features only because you want to support
> older versioning software, that does not provide the necessary
> infrastructure.
>
> Just my 2 cents.
>
> For the original discussion, about why use SQL for the wiki, I asked
> myself the same question, when I first read about Trac. Another writer
> also stated that it would be wonderful, if some project documentation
> (now stored in the wiki) could be part of the svn repository itself.
> This looks like a task for an InterWiki. Having different wiki store
> backends that can reside in different places come into my mind.
>
> For the WIKI and SQL issue: There was some discussion to add an SQL
> backend to subversion as a 2.0 feature. Don't know wether this is
> still true. But perhaps trac can use this backend to store changing
> wiki pages within a SQL database without loosing the possibility of
> querying the database itself.
> After I have converted our VSS repository to subversion, I will also
> start using TRAC. For what I have seen right now, it is a good peace
> of software.
>
> Best regards
> Dirk
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac

Nice... where would this macro be available from ;-?

mario


On Aug 18, 2004, at 2:22 PM, Fran?ois Harvey wrote:
> As a work around what about a new macro
>
> [[Include(File or Wiki)FromSVN('/path/inside/subversion') ]]
>
> work for wiki page, but also for included some source code (ex sample
> or contrib) , doc, etc.
>
> Francois Harvey
> SecuriWeb inc.
>
> trac@nogga.de wrote:
>
>> Hi,
>>
>>> I read that Trac future features include support for alternative
>>> source control software. Adding a dependency on a specific one
>>> should
>>> be avoided.
>>
>>
>> I would even vote for a tighter integration of trac and subversion
>> (e.g. a post-2010 issue to have subversion and trac merged together
>> :-). The reason for my opinion is, that having this design goal is a
>> nice developer task, but it only cuts trac down in possible features.
>> If you try to find a common interface for different version control
>> software you can necessarily only support those feautres available in
>> all versioning software. You will loose all features available
>> through subversion, esp. unique revision numbers, changesets (and
>> perhaps custom properties)
>>
>> There are a lot of tools available that integrate with other
>> versioning tools like bugzilla, I think, there is even a CVSTrac
>> software available. There is no need to gain some importance in using
>> trac with cvs e.g.
>>
>> Trac looks very promising and has the power to build an high grade
>> integrated IssueTracking, Wiki, ProjectManagment, Documentation, and
>> so forth tool. Don't cut features only because you want to support
>> older versioning software, that does not provide the necessary
>> infrastructure.
>>
>> Just my 2 cents.
>>
>> For the original discussion, about why use SQL for the wiki, I asked
>> myself the same question, when I first read about Trac. Another
>> writer also stated that it would be wonderful, if some project
>> documentation (now stored in the wiki) could be part of the svn
>> repository itself. This looks like a task for an InterWiki. Having
>> different wiki store backends that can reside in different places
>> come into my mind.
>>
>> For the WIKI and SQL issue: There was some discussion to add an SQL
>> backend to subversion as a 2.0 feature. Don't know wether this is
>> still true. But perhaps trac can use this backend to store changing
>> wiki pages within a SQL database without loosing the possibility of
>> querying the database itself.
>> After I have converted our VSS repository to subversion, I will also
>> start using TRAC. For what I have seen right now, it is a good peace
>> of software.
>>
>> Best regards
>> Dirk
>>
>> _______________________________________________
>> Trac mailing list
>> Trac@lists.edgewall.com
>> http://lists.edgewall.com/mailman/listinfo/trac
>
>
> _______________________________________________
> Trac mailing list
> Trac@lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac