Re: [Trac] Warning: Version missmatch Ubuntu Lucid, Trac , jQuery
Hi, currently I'm very busy with real life, so just a few hints: - about missing jQuery 1.2, there is an open bug in Debian, that affects also Ubuntu: http://bugs.debian.org/562859 - please try package version 0.11.7-3 instead of 0.11.7-1, this should fix the broken jQuery link at least, it's in the latest Ubuntu incarnation - don't expect 0.12 soon in Debian and/or Ubuntu; while many people would like to have it, somebody would have to do the work :~) See http://bugs.debian.org/563391 HTH! Quoting Olemis Lang ole...@gmail.com: I continued my research so as to finally use Trac in Ubuntu 10.04 LTS Lucid . -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Trac 0.12 and local translations
On Tue, May 25, 2010 at 5:43 AM, Roger Oberholtzer roger.oberholt...@gmail.com wrote: I have not installed local translations in my 0.12b1 release. I am waiting for the next release. But I am curious about one thing: when a text field is doing spell checks, what language will be used? Now it is English. What if I set my language to something else? I suppose that needs to be configured in the browser (e.g. using Opera , right click on the text area , then select Check spelling and then choose the target language) . You should have installed the required dictionaries before doing so ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Demanda sobre patente impide distribuir Microsoft Word - http://feedproxy.google.com/~r/simelo-es/~3/DwuBKpveLTg/demanda-sobre-patente-impide-distribuir.html -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Warning: Version missmatch Ubuntu Lucid, Trac , jQuery
On Tue, May 25, 2010 at 5:45 AM, W. Martin Borgert deba...@debian.org wrote: Quoting Olemis Lang ole...@gmail.com: I continued my research so as to finally use Trac in Ubuntu 10.04 LTS Lucid . Hi, :o) currently I'm very busy with real life, so just a few hints: - about missing jQuery 1.2, there is an open bug in Debian, that affects also Ubuntu: http://bugs.debian.org/562859 ok - please try package version 0.11.7-3 instead of 0.11.7-1, this should fix the broken jQuery link at least, it's in the latest Ubuntu incarnation Hmmm ... seems my repos is not up to date :-$ - don't expect 0.12 soon in Debian and/or Ubuntu; while many people would like to have it, somebody would have to do the work :~) See http://bugs.debian.org/563391 In a separate thread I asked for tools, guidelines and | or procedure to package trac and its plugins . Even if this is OT here, any hints will be appreciated (and I can wait, «real life» is «real» for me too, so I understand ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: TracMac: `mainnav` is ready (only the apple is missing ;o). - http://simelo.hg.sourceforge.net/hgweb/simelo/trac-macos/rev/52f72c39f29e -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Re: edit large wiki pages impossible
server latency + network latency timeout where can i change this timeout time? On every web browser connecting to it, if it can be changed at all. It's a client side setting, and varies by browser. Either make your server or your network faster. That is not in my power. Then I think you either need to find someone in charge of your network and have them fix it, or you're out of luck. I mean, if you run a ping for a long period of time, do you see high latency/packet loss? If so, then that is something you might be able to take to the person responsible for the network to demonstrate that it is broken. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
Sorry to hijack but I was just wondering if you have any specific reasons for choosing mysql over e.g. PostgreSQL. I don't know that much about dBs really so any thoughts welcome. I picked PostgreSQL as it seemed the better supported in Trac... As did I. However, I wish I hadn't. My reasons, however, are largely subjective. Arguments for MySQL over PostgreSQL: - MySQL is syntactically much closer to SQLite than PostgreSQL is, so the transition is less dramatic (changing code for plugins with embedded SQL queries, raw SQL report port overs, etc.) - The permission scheme for MySQL makes more sense to me. - The overall feel of using PostgreSQL is more akin to using an old-style database (Oracle/DB2). This makes sense, given its heritage, but makes it feel old and crufty. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
[Trac] Button instead of Macro Processor
Hi there!
I'm creating a macro for Trac which should check,
if parenthesis are correctly opened and closed. Until now,
I wrote a macro, which is able to do the job.
I need your help on two issues:
1 - How do it looks like, if I want to, let's say,
have a button on my wiki, which when clicked,
simply processes the text, without the need for
something like '#!macro' in the code.
2 - If I do let the macro commando in my wiki text,
how can I avoid that {{{ }}}(blocks) are escaped?
Ex.:
{{{
#!myMacro
{{{
Here is a piece text, that should be processed, but shown as block!
}}}
}}}
So, I want to have the text processed
without the intern {{{ }}} being literally shown.
Until now I'm using something like this to show the wiki content:
return 'pre class=wiki%s/pre' %text
I would be really thankful, if someone could help me!
Best greetings,
Rodrik.
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Button instead of Macro Processor
You should probably be more specific about what you are trying to do. There
is a decent chance that a wiki is not what you should be using if you want
things like dynamic syntax processing.
--Noah
-Original Message-
From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com]
On Behalf Of Rodrik
Sent: Tuesday, May 25, 2010 10:39 AM
To: trac-users@googlegroups.com
Subject: [Trac] Button instead of Macro Processor
Hi there!
I'm creating a macro for Trac which should check,
if parenthesis are correctly opened and closed. Until now,
I wrote a macro, which is able to do the job.
I need your help on two issues:
1 - How do it looks like, if I want to, let's say,
have a button on my wiki, which when clicked,
simply processes the text, without the need for
something like '#!macro' in the code.
2 - If I do let the macro commando in my wiki text,
how can I avoid that {{{ }}}(blocks) are escaped?
Ex.:
{{{
#!myMacro
{{{
Here is a piece text, that should be processed, but shown as block!
}}}
}}}
So, I want to have the text processed
without the intern {{{ }}} being literally shown.
Until now I'm using something like this to show the wiki content:
return 'pre class=wiki%s/pre' %text
I would be really thankful, if someone could help me!
Best greetings,
Rodrik.
--
You received this message because you are subscribed to the Google
Groups Trac Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to trac-
users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Backend dB choice
And for comparison, reasons to avoid MySQL: Unicode collation is a train wreck. UTF8 storage is scarily inefficient. Much ambiguity about the future of the project since the Oracle takeover. --Noah From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Matt Caron Sent: Tuesday, May 25, 2010 5:57 AM To: trac-users@googlegroups.com Subject: Re: [Trac] Backend dB choice Sorry to hijack but I was just wondering if you have any specific reasons for choosing mysql over e.g. PostgreSQL. I don't know that much about dBs really so any thoughts welcome. I picked PostgreSQL as it seemed the better supported in Trac... As did I. However, I wish I hadn't. My reasons, however, are largely subjective. Arguments for MySQL over PostgreSQL: - MySQL is syntactically much closer to SQLite than PostgreSQL is, so the transition is less dramatic (changing code for plugins with embedded SQL queries, raw SQL report port overs, etc.) - The permission scheme for MySQL makes more sense to me. - The overall feel of using PostgreSQL is more akin to using an old-style database (Oracle/DB2). This makes sense, given its heritage, but makes it feel old and crufty. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
Disclaimer: I have no real DB-knowledge. Just curious - what are the shortcomings of the default and simple SQLite, compared to the other options? Itamar O. On Tue, May 25, 2010 at 10:13 PM, Noah Kantrowitz n...@coderanger.netwrote: And for comparison, reasons to avoid MySQL: Unicode collation is a train wreck. UTF8 storage is scarily inefficient. Much ambiguity about the future of the project since the Oracle takeover. --Noah *From:* trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] *On Behalf Of *Matt Caron *Sent:* Tuesday, May 25, 2010 5:57 AM *To:* trac-users@googlegroups.com *Subject:* Re: [Trac] Backend dB choice Sorry to hijack but I was just wondering if you have any specific reasons for choosing mysql over e.g. PostgreSQL. I don't know that much about dBs really so any thoughts welcome. I picked PostgreSQL as it seemed the better supported in Trac... As did I. However, I wish I hadn't. My reasons, however, are largely subjective. Arguments for MySQL over PostgreSQL: - MySQL is syntactically much closer to SQLite than PostgreSQL is, so the transition is less dramatic (changing code for plugins with embedded SQL queries, raw SQL report port overs, etc.) - The permission scheme for MySQL makes more sense to me. - The overall feel of using PostgreSQL is more akin to using an old-style database (Oracle/DB2). This makes sense, given its heritage, but makes it feel old and crufty. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.comtrac-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.comtrac-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Backend dB choice
The biggest problem with SQLite is that it has a very simple locking model. More or less, if someone is writing to the DB no one else can touch it. Speed-wise it compares pretty well to most other DBs, it just doesn't scale up in terms of concurrency. This isn't a problem for most people, but if you have more than a dozen people using a Trac site full-time it can get annoying. --Noah From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Itamar O Sent: Tuesday, May 25, 2010 12:20 PM To: trac-users@googlegroups.com Subject: Re: [Trac] Backend dB choice Disclaimer: I have no real DB-knowledge. Just curious - what are the shortcomings of the default and simple SQLite, compared to the other options? Itamar O. On Tue, May 25, 2010 at 10:13 PM, Noah Kantrowitz n...@coderanger.net wrote: And for comparison, reasons to avoid MySQL: Unicode collation is a train wreck. UTF8 storage is scarily inefficient. Much ambiguity about the future of the project since the Oracle takeover. --Noah From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of Matt Caron Sent: Tuesday, May 25, 2010 5:57 AM To: trac-users@googlegroups.com Subject: Re: [Trac] Backend dB choice Sorry to hijack but I was just wondering if you have any specific reasons for choosing mysql over e.g. PostgreSQL. I don't know that much about dBs really so any thoughts welcome. I picked PostgreSQL as it seemed the better supported in Trac... As did I. However, I wish I hadn't. My reasons, however, are largely subjective. Arguments for MySQL over PostgreSQL: - MySQL is syntactically much closer to SQLite than PostgreSQL is, so the transition is less dramatic (changing code for plugins with embedded SQL queries, raw SQL report port overs, etc.) - The permission scheme for MySQL makes more sense to me. - The overall feel of using PostgreSQL is more akin to using an old-style database (Oracle/DB2). This makes sense, given its heritage, but makes it feel old and crufty. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com mailto:trac-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com mailto:trac-users%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en. -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
Noah Kantrowitz wrote: The biggest problem with SQLite is that it has a very simple locking model. More or less, if someone is writing to the DB no one else can touch it. This. Once we got to about 20 people using it, someone would run a long query and it would lock everyone out with Database is locked messages. -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
Noah Kantrowitz wrote: And for comparison, reasons to avoid MySQL: Much ambiguity about the future of the project since the Oracle takeover. Theoretically, one should be able to use MariaDB, though I have not tested this. But yes, I share your fears as to what SnOracle will do... -- SIXNET - Industrial and Wireless Connectivity 331 Ushers Road, Ballston Lake, NY 12019 Tel: 1.518.877.5173, Fax: 1.518.877.8346 www.sixnet.com -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Button instead of Macro Processor
Hi Noah,
Noah Kantrowitz n...@... writes:
You should probably be more specific about what you are trying to do. There
is a decent chance that a wiki is not what you should be using if you want
things like dynamic syntax processing.
--Noah
-Original Message-
From: trac-us...@... [mailto:trac-us...@...]
On Behalf Of Rodrik
Sent: Tuesday, May 25, 2010 10:39 AM
To: trac-us...@...
Subject: [Trac] Button instead of Macro Processor
Hi there!
I'm creating a macro for Trac which should check,
if parenthesis are correctly opened and closed. Until now,
I wrote a macro, which is able to do the job.
I need your help on two issues:
1 - How do it looks like, if I want to, let's say,
have a button on my wiki, which when clicked,
simply processes the text, without the need for
something like '#!macro' in the code.
2 - If I do let the macro commando in my wiki text,
how can I avoid that {{{ }}}(blocks) are escaped?
Ex.:
{{{
#!myMacro
{{{
Here is a piece text, that should be processed, but shown as block!
}}}
}}}
So, I want to have the text processed
without the intern {{{ }}} being literally shown.
Until now I'm using something like this to show the wiki content:
return 'pre class=wiki%s/pre' %text
I would be really thankful, if someone could help me!
Best greetings,
Rodrik.
--
You received this message because you are subscribed to the Google
Groups Trac Users group.
To post to this group, send email to trac-us...@...
To unsubscribe from this group, send email to trac-
users+unsubscr...@...
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
What I'm trying to do is to check if parenthesis in texts
inserted into the wiki are balanced, i.e. if each '(' has its respective ')'.
I have to do it for project, where people will insert text into the wiki,
so I can't bypass it.
My code looks something like this:
class SyntaxChecker(WikiMacroBase):
def checkParentheses(string):
//check if ()'s are balanced
def get_macros(self):
//some code
def expand_macro(self, formatter, name, args):
text = ''
if args:
lines = args.split('\n')
for line in lines:
if not checkParentheses(line): //if ()' are not balanced
text += 'h1 style=text-align: left; color:
red%s/h1\n'
%line.replace(,).replace(,)+'\n'
else: //if ()'s are OK
text += line.replace(,).replace(,)+'\n'
return 'pre class=wiki%s/pre' %text //How would be the best
way to do this?
Thanks in advance for your help!
Rodrik.
--
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-us...@googlegroups.com.
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
* On 25 May 2010, Matt Caron wrote: Noah Kantrowitz wrote: And for comparison, reasons to avoid MySQL: Much ambiguity about the future of the project since the Oracle takeover. Theoretically, one should be able to use MariaDB, though I have not tested this. But yes, I share your fears as to what SnOracle will do... Why? What is the much ambiguity? Oracle have publicly declared that MySQL will be an important piece of their strategy and that it will be supported on par and in parallel with the flagship. Is there specific reason to doubt that or you're just generally suspicious of Oracle? That's fine, I don't love a megacorp, but let's be clear. I hear a great deal of FUD about former Sun products since (before) the buyout and I think it harms the community unnecessarily. As much as I personally would enjoy seeing MySQL suffer, I want it to suffer on concrete grounds, not from mistrust and fear. To add relevant content, I switched from sqlite3 to mysql on a test instance just to make sure I wasn't being naive about performance. I wasn't. Sqlite performed as well as mysql for our low-concurrency workload. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
RE: [Trac] Backend dB choice
-Original Message- From: trac-users@googlegroups.com [mailto:trac-us...@googlegroups.com] On Behalf Of David Champion Sent: Tuesday, May 25, 2010 2:27 PM To: trac-users@googlegroups.com Subject: Re: [Trac] Backend dB choice * On 25 May 2010, Matt Caron wrote: Noah Kantrowitz wrote: And for comparison, reasons to avoid MySQL: Much ambiguity about the future of the project since the Oracle takeover. Theoretically, one should be able to use MariaDB, though I have not tested this. But yes, I share your fears as to what SnOracle will do... Why? What is the much ambiguity? Oracle have publicly declared that MySQL will be an important piece of their strategy and that it will be supported on par and in parallel with the flagship. Is there specific reason to doubt that or you're just generally suspicious of Oracle? That's fine, I don't love a megacorp, but let's be clear. I hear a great deal of FUD about former Sun products since (before) the buyout and I think it harms the community unnecessarily. As much as I personally would enjoy seeing MySQL suffer, I want it to suffer on concrete grounds, not from mistrust and fear. This is starting to drift off-topic, but the rapid departure of many of the prominent FOSS people from Sun has me worried. Most have left very suddenly, refusing to discuss their exact reasons for leaving except to say they no longer felt comfortable with the environment at Oracle. The few I know personally I put a great deal of trust in their judgement, and if they say the climate at Oracle was a problem, I believe it. There has been no overt action taken against MySQL, but if Oracle really does have culture problems with FOSS (and it seems that they do) it doesn't bode well for the health of the project long-term. Sure it could be forked and managed independently of Oracle (see Ethereal-Wireshark), but those kinds of events usually end up fracturing the community and reducing development to a standstill for a while. People ask Why not use MySQL?, but I see it as Why take the risk on MySQL?. There is no real technical advantage MySQL has over Postgres (and vice versa). Performance measurements are basically neck and neck and change a little each time you ask. Feature-wise, I guess I just don't use that many advanced features of either and I suspect that many on either side of the debate don't either. --Noah -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
Re: [Trac] Backend dB choice
* On 25 May 2010, Noah Kantrowitz wrote: This is starting to drift off-topic, but the rapid departure of many of the prominent FOSS people from Sun has me worried. Most have left very suddenly, ... Ah, that is good information and something I put stock in. on MySQL?. There is no real technical advantage MySQL has over Postgres (and vice versa). Performance measurements are basically neck and neck and change a little each time you ask. Feature-wise, I guess I just don't use that many advanced features of either and I suspect that many on either side of the debate don't either. Agreed. MySQL seems to have a great deal of clout, but no real performance or technological edge. Personally I prefer the simplicity and reduced dependency profile of an embedded db like sqlite, up to the point that these advantages cause performance problems in a real scenario. Then I look to Postgres -- which, while it has a connection to Oracle (via Sun) as well, is not a wholly-owned property. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago -- You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-us...@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
