Wow!! You're great help...where do I click to give 5-star rating?? >I have no idea what that is like at all. Seriously. ;-)
How I wish I could be the same!! Right now, its about 3-4 ppl who'll be working on the server, of which only 1-2 might work simultaneously. So, from what you're saying I guess its not necessary to have a MySQL DB. But since the Snow Leopard server comes with MySQL pre-installed, we'll probably move to that when we install trac on the server. In the meantime, I'll try and get another trac project running with MySQL(after the installation procedure as you've explained in the mail) on my system. I hope this is possible - to run a trac project on sqlite while the other runs on mysql (both standalone). This would ease my paranoia of being able to set it up with MySQL on the server later on. Is the Trac website the best place to direct new users to, to get a basic idea of how it works? Matthew Caron-2 wrote: > > On 11/11/2010 04:14 AM, cap_sue wrote: >> Thanks a lot for your input and sorry that I have taken so long to >> respond. >> I was working on other stuff and only got back to the Trac installation >> now. > > I have no idea what that is like at all. Seriously. ;-) > > (No worries) > >> I have successfully managed to create authentication and once logged in, >> I >> can see the New Ticket field. > > Excellent. > >> I have another (or a few) question(s). > > Ask away. > >> Would it be possible to continue using sqlite for actual bugtracking >> purposes or will i run out of database space soon and/or are the feature >> in >> sqlite very limited compared to MySQL? In other wods, what would be the >> advantage of going with MySQL as opposed to sqlite. > > MySQL is a real database server. It has a finer granularity of locking, > better concurrency, less latency, etc. > > SQLite is a database engine, suitable for small installations and > embedding into applications. It is easier to set up, as you don't have > to set up a daemon, tweak much of anything, worry that much about > security, etc. > > You won't really run into space issues with either, until you run out of > disk space. You also won't (generally) run into compatibility/feature > issues as Trac is programmed to be reasonably database abstract. > However, you might run into problems with plugins which call direct SQL > commands rather than the Trac API, as they may not have been programmed > as conservatively as core Trac is. This is generally not a big deal - > fix the SQL until it works, file a bug with the plugin maintainer, > submit a patch, get on with life. > > That said, you will likely run into scalability issues. If you're > supporting two users, and don't intend in going over about five people > in the near future, then don't worry about it - just use SQLite. Once > you hit about 5-10 heavy users, however, you'll start seeing issues with > people stepping on each other (you'll start seeing "database is locked" > timeout errors) and then you'll need to migrate to a real DB server. > > Also note that any custom reports you do will be all on you. I've > specifically run into variances with time-related ones, as MySQL, > PostgreSQL and SQLite all have different date-handling functions. Also, > the quoting can be subtly different (PostgreSQL wants single quotes). > >> We do have a SnowLeopard Server which I can use to install trac once I >> establish trac is working fine on my system. In that case, I do have >> MySQL >> pre-installed on the Server OS. Would there be a big difference in the >> procedure to set up the trac project if I went for a MySQL DB? > > Depends on how paranoid you are and how much functionality you need. > > With SQLite, you just point the ini file at the file you want to use > and, once it is created, restrict permissions so someone else can't fire > up the SQLite CLI client and modify it, while not breaking the > permissions necessary for trac to work. Generally, the correct owner and > permissions 0644 do the trick, which also means your nightly stats > gathering scripts can dump the db to, say, email each manager a summary > of the day's events. > > With MySQL, you (or, at least I) > - Install it > - Create root user > - Create empty trac db > - Create trac user with access only to that db > - Point trac.ini at that DB with those credentials > - Since trac.ini now has credentials, lock it down so no one can read > it except those who need to > - Create a readonly user with SELECT permissions (so that nightly > scripts can query the DB, as mentioned above) > > It's is not particularly difficult, just a little bit more work. > -- > Matthew Caron > Build Engineer > Sixnet | www.sixnet.com > O +1 518 877 5173 Ext. 138 > F +1 518 602 9209 > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Trac Users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/trac-users?hl=en. > > > -- View this message in context: http://old.nabble.com/Trac-on-OSX-tp30026741p30215535.html Sent from the Trac Users mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
