| [00:09:02] |
* |
neoxed has quit IRC |
| [00:24:30] |
* |
neoxed has joined #Trac |
| [00:42:17] |
* |
chtito has joined #trac |
| [01:09:40] |
* |
sabi has joined #trac |
| [01:43:06] |
* |
m_g has joined #trac |
| [02:23:43] |
* |
eblot_ has joined #trac |
| [02:41:02] |
* |
eblot has quit IRC |
| [02:42:56] |
* |
chtito has quit IRC |
| [03:14:15] |
<m_g> |
hmm i have the feeling that PythonInterpreter main_interpreter slows down trac, is that possible? |
| [03:23:33] |
<mitsuhiko> |
m_g: what do you mean by main_interpreter? |
| [03:24:31] |
<m_g> |
mitsuhiko, it's been suggested to add PythonInterpreter main_interpreter to all trac vhosts to avoid the restricted mode problem (#3455, #2611, #3371) |
| [03:25:21] |
<mitsuhiko> |
m_g: mod_python? |
| [03:25:25] |
<m_g> |
yup |
| [03:25:27] |
<mitsuhiko> |
ah |
| [03:25:28] |
<sabi> |
you could always not use mod_python :) |
| [03:25:35] |
* |
mitsuhiko hates mod_python |
| [03:25:46] |
<m_g> |
fcgi guys, eh? :) |
| [03:25:58] |
<sabi> |
for me, yes... i've not had problems with trac + mod_fcgid |
| [03:28:48] |
<mitsuhiko> |
m_g: jep |
| [03:34:03] |
<m_g> |
well, never touch a running system :) |
| [03:42:27] |
* |
Igloo has left #trac |
| [03:44:45] |
* |
Sweetshark has joined #trac |
| [03:47:14] |
* |
Sweetsha1k has quit IRC |
| [04:01:52] |
* |
eblot_ has quit IRC |
| [04:12:22] |
* |
Miek has quit IRC |
| [04:29:31] |
* |
eblot has joined #trac |
| [04:51:26] |
* |
rgl has joined #trac |
| [04:51:27] |
<rgl> |
hi |
| [05:15:51] |
* |
s0undt3ch has joined #trac |
| [05:23:33] |
<tessier_> |
Where is svn.py supposed to come from? |
| [05:23:43] |
<tessier_> |
I just installed pysvn which consists of just a couple files. |
| [05:24:05] |
<tessier_> |
__init__.py and _pysvn.so |
| [05:24:15] |
<tessier_> |
From python I can do an import pysvn with no problem |
| [05:24:18] |
<tessier_> |
But I can't do an import svn |
| [05:26:31] |
* |
pygi has joined #trac |
| [05:29:51] |
<tessier_> |
I bet my svn is too old. |
| [05:30:45] |
<pygi> |
prologic,ping |
| [05:33:03] |
<tessier_> |
soooo many dependencies... |
| [05:35:28] |
* |
Jeena_ has joined #trac |
| [05:35:34] |
<Jeena_> |
Hi |
| [05:36:06] |
<Jeena_> |
I have installed trac for my weblogsoftware here: http://jeenaparadies.net/projects/jlog/ |
| [05:36:44] |
<Jeena_> |
but now I need to install a demo blog within this project |
| [05:37:03] |
<Jeena_> |
is ist possible to use http://jeenaparadies.net/projects/jlog/demo/ or something like that? |
| [05:37:17] |
* |
eblot has left #trac |
| [05:37:30] |
<Jeena_> |
if it is, where do I install it, or how? |
| [05:38:32] |
<blinx> |
re |
| [05:46:17] |
* |
pygi has quit IRC |
| [06:16:47] |
<tessier_> |
TracError: Unsupported version control system "svn" |
| [06:16:48] |
<tessier_> |
grrr |
| [06:18:13] |
* |
Jeena_ has left #trac |
| [06:25:46] |
* |
rgl has quit IRC |
| [06:28:37] |
* |
tessier_ sighs |
| [06:28:43] |
<tessier_> |
Time to go to bed. Defeated. |
| [06:55:45] |
* |
demianturner has joined #trac |
| [06:55:58] |
<demianturner> |
afternoon all |
| [06:56:41] |
<demianturner> |
anyone getting "OperationalError: database is locked" with 0.10.2 ? |
| [06:59:03] |
* |
rgl has joined #trac |
| [06:59:30] |
* |
demian__ has joined #trac |
| [07:06:40] |
* |
chtito has joined #trac |
| [07:16:19] |
* |
demianturner has quit IRC |
| [07:30:17] |
* |
converter has joined #trac |
| [07:52:41] |
* |
Jasper^ has joined #trac |
| [08:00:12] |
* |
jborg has joined #trac |
| [08:30:12] |
* |
flox has quit IRC |
| [08:37:38] |
* |
dilinger has quit IRC |
| [08:48:13] |
* |
gakman has joined #trac |
| [08:58:06] |
* |
gak has quit IRC |
| [08:58:40] |
* |
cboos has joined #trac |
| [09:00:41] |
<cboos> |
hi |
| [09:01:39] |
<cboos> |
hey, jonas did some big work on the wiki this W.E., passing the "rendering context" around ... big changeset ahead ;) |
| [09:01:49] |
* |
flox has joined #trac |
| [09:03:26] |
<cboos> |
(I meant: hey, jonas, I did some ... ) |
| [09:04:44] |
<jborg> |
oh, cool |
| [09:05:09] |
<cboos> |
yes, I'm quite satisfied with the result |
| [09:05:32] |
<cboos> |
(currently writing a big commit message documenting everything) |
| [09:08:22] |
<jborg> |
Will this go into trunk or a branch? |
| [09:08:43] |
<cboos> |
well, I don't want to see that code sit in a branch for a few months, so in trunk ;) |
| [09:08:59] |
<cboos> |
but I have heavily tested it the whole week-end, so I think it's quite safe |
| [09:09:49] |
<cboos> |
(plus we have this heavy policy about branch creation ...) |
| [09:11:23] |
<jborg> |
maybe, but that should not be used as an excuse for committing major changes directly into trunk without discussing the approach on trac-dev |
| [09:11:54] |
<jborg> |
but I have no idea how big and invasive it really is, if it's not that big it might be ok |
| [09:11:55] |
<cboos> |
well, the approach has been exposed in the relevant tickets since a while now ... |
| [09:12:36] |
<cboos> |
anyway, when I try to discuss things on Trac-Dev, one can't say that the answers are overwhelming ... |
| [09:13:27] |
<cboos> |
(there wasn't even a lot of +1 / -1 / +/- 0 on the Generic Trac branch proposal) |
| [09:14:02] |
<jborg> |
yeah I know, everybody seem to be very busy right now. But I think we still should not give up on this approach. |
| [09:14:26] |
<cboos> |
well, I'm quite open to suggestions and feedback, as I'm sure you know |
| [09:14:40] |
<cboos> |
so if something ends in trunk, that doesn't necessarily mean it's set in stone |
| [09:16:08] |
<cboos> |
take the option Config stuff... that was a refactoring that was not that important. Though that got discussed a length between cmlenz and me. I was ok with his suggestions... but then, a few weeks later, he took a different path, and just committed the new approach. |
| [09:17:41] |
<cboos> |
I was OK with that, as the new code was even better, but nevertheless, one could question whether: 1) I couldn't have taken the same route as him (just commit the stuff then refine) -- 2) or he could have done the same as me ... ask for feedback first |
| [09:18:51] |
<cboos> |
... so I think it boils down to: 1/ when you're confident enough the code is good, just commit it 2/ when you'd like to have feedback, ask for feedback |
| [09:19:23] |
<cboos> |
That being said, I can paste the commit log and the diff somewhere if you'd like to take a look |
| [09:22:11] |
<mitsuhiko> |
hoi cboos |
| [09:22:18] |
<mitsuhiko> |
cboos: anything new on the wiki formatter stuff? |
| [09:22:20] |
<cboos> |
hello |
| [09:22:26] |
<jborg> |
cboos, I think option number 1 works best most of the time but depending on the complexity/impact option 2 might be the way to go. |
| [09:23:20] |
<cboos> |
jborg: well, yes, the impact is moderately big, but much in line with the current evolution (nothing revolutionary) |
| [09:23:43] |
<cboos> |
mitsuhiko: yeah, I've added the notion of rendering contexts |
| [09:24:13] |
<cboos> |
mitsuhiko: nothing new on the parsing/formatting side, but rather on the way the context information is carried along |
| [09:24:30] |
<mitsuhiko> |
cboos: i played around with my lexing module but it's terrible slow :( |
| [09:24:32] |
<mitsuhiko> |
http://trac.pocoo.org/browser/tekisuto/trunk/tests/moinlexer.py |
| [09:25:02] |
<cboos> |
e.g. most visible change, the render_macro now takes a formatter argument, itself knowing about it's 'context' |
| [09:25:18] |
<cboos> |
mitsuhiko: have you taken a look at how DrProject does it? |
| [09:25:25] |
<cboos> |
they use a lexer too, I think |
| [09:25:43] |
<cboos> |
(they also report it's terribly slow ;) ) |
| [09:25:55] |
<cboos> |
s/report/reported/ I don't know what's the current status |
| [09:26:06] |
<mitsuhiko> |
cboos: my problem is, the more rules the slower |
| [09:26:19] |
<mitsuhiko> |
because for each unlexed character it fires up all formatting rules until something is found |
| [09:26:32] |
<cboos> |
yeah, that doesn't happen with regexps, does it? |
| [09:26:49] |
* |
rgl has quit IRC |
| [09:26:58] |
<mitsuhiko> |
no |
| [09:27:05] |
<mitsuhiko> |
it's not so a big problems with regexes only |
| [09:27:17] |
<cboos> |
... but IMO, while the parsing/formatting separation is a good thing to do, we don't need to give up on using regexps. |
| [09:27:36] |
<cboos> |
i.e. using regexps doesn't prevent us to implement this separation of concerns |
| [09:27:37] |
<mitsuhiko> |
i'll try to create a regex only version of the whole stuff the |
| [09:28:07] |
<cboos> |
jborg: so ... you'd like to take a look at my changes? |
| [09:28:10] |
<mitsuhiko> |
the advantage of my current approach is that lexing/parsing/formatting is independent of each other |
| [09:28:55] |
<mitsuhiko> |
cboos: are your changes already in trunk? |
| [09:29:19] |
<cboos> |
not yet, that's what I've been discussing with jborg just above |
| [09:29:33] |
* |
mitsuhiko reads chatlog |
| [09:30:03] |
<jborg> |
cboos, sure, I can have a look, can you upload a diff or something? |
| [09:30:32] |
<cboos> |
yes, in about 5 minutes (just trying to fix a last issue with the PageOutline...) |
| [09:30:55] |
<jborg> |
cboos, btw, what do you think about #4363, should the "is" and "is not" query filters be case insensitive as well? |
| [09:32:05] |
<cboos> |
is ~= case insensitive? |
| [09:32:35] |
<mitsuhiko> |
cboos: have you ever checked out wiki_text? |
| [09:32:45] |
<cboos> |
"is" is intuitively more like an exact match, so I'd say it's ok like that |
| [09:32:52] |
<cboos> |
mitsuhiko: no |
| [09:33:19] |
<mitsuhiko> |
it basically tries to do the same i do but in place and with null byte hacks. but it's much faster |
| [09:33:31] |
<mitsuhiko> |
probably because php has mutable strings :-/ |
| [09:33:48] |
<cboos> |
well, I could take a look, yes. |
| [09:33:51] |
<cboos> |
ah, speaking of the wiki, what do you think about the Wiki Creole stuff? |
| [09:34:25] |
<cboos> |
@ticket 3936 |
| [09:34:25] |
<evil_twin> |
cboos: http://trac.edgewall.org/ticket/3936 |
| [09:34:39] |
<mitsuhiko> |
cboos: i don't like their syntax |
| [09:34:45] |
<cboos> |
hm, no wrong ticket wait |
| [09:34:46] |
<mitsuhiko> |
especially the list formatting is strange |
| [09:34:53] |
<cboos> |
right |
| [09:34:58] |
<mitsuhiko> |
cboos: i know the ticket :) |
| [09:35:15] |
<mitsuhiko> |
@ticket 4356 |
| [09:35:15] |
<evil_twin> |
mitsuhiko: http://trac.edgewall.org/ticket/4356 |
| [09:35:22] |
<cboos> |
thx |
| [09:35:38] |
<cboos> |
yeah, in my patch I just added support for bold and italic and the links |
| [09:36:28] |
<cboos> |
I think that would be nice to have, as it's also very close to DokuWiki, and we hear a lot from people transitioning from DokuWiki to Trac |
| [09:36:52] |
<cboos> |
(plus the patch doesn't break anything) |
| [09:37:43] |
* |
dilinger has joined #trac |
| [09:37:50] |
<mitsuhiko> |
i really like the moin syntax |
| [09:37:59] |
<mitsuhiko> |
just the link syntax stuff is heavily broken |
| [09:38:09] |
<mitsuhiko> |
fortunately trac uses a different link syntax |
| [09:38:27] |
<cboos> |
well, aren't we MoinMoin compatible with links? |
| [09:38:34] |
<mitsuhiko> |
really? |
| [09:38:40] |
* |
mitsuhiko tries out |
| [09:38:47] |
<cboos> |
I thought so, but maybe didn't check in the details... |
| [09:39:01] |
<mitsuhiko> |
woa. wicked |
| [09:39:03] |
<mitsuhiko> |
["foo"] works |
| [09:39:15] |
<mitsuhiko> |
ah. but [:foo: title] not |
| [09:39:56] |
<cboos> |
that's useful when you want to write things like: What's a ["Changeset"]? or see all the ["Changeset"]s. |
| [09:40:07] |
<cboos> |
what does [:foo: title] do? |
| [09:40:15] |
<cboos> |
i.e. what's :foo: |
| [09:41:00] |
<mitsuhiko> |
[wiki:foo Title] |
| [09:41:15] |
<mitsuhiko> |
cboos: in fact it's an interwiki link to unnamed wiki which is the local one |
| [09:42:40] |
<cboos> |
hm... |
| [09:43:07] |
<mitsuhiko> |
cboos: i guess trac doesn't need that syntax |
| [09:43:36] |
<mitsuhiko> |
cboos: http://trac.pocoo.org/browser/tekisuto/trunk/tests/moinlexer.py#L134 |
| [09:43:41] |
<cboos> |
yes, except maybe if it's about being compatible ... |
| [09:43:45] |
<mitsuhiko> |
that are all ways of moin linking i know |
| [09:53:51] |
<cboos> |
jborg: "uploaded" |
| [09:53:55] |
<cboos> |
@wiki WikiContext |
| [09:53:55] |
<evil_twin> |
cboos: http://trac.edgewall.org/wiki/WikiContext |
| [09:57:14] |
* |
converter has quit IRC |
| [09:57:17] |
<jborg> |
cboos, ok, I'll have a look |
| [09:58:28] |
<cboos> |
thanks. Bear in mind this is not entirely "new" stuff, I've discussed the need of context a few times with cmlenz, and he was OK with the idea (admittedly he didn't get to see the code itself) |
| [10:00:04] |
* |
cboos will distribute bonus points if one discovers that the context is a bit the TracObject in disguise, minus the model part, plus the generality needed for the PermissionPolicy |
| [10:14:39] |
* |
demian__ has quit IRC |
| [10:14:58] |
<jborg> |
I've looked through the patch a bit now and it looks very good. |
| [10:15:01] |
* |
idnar has quit IRC |
| [10:15:04] |
* |
idnar_ has joined #trac |
| [10:15:05] |
* |
demianturner has joined #trac |
| [10:15:09] |
<cboos> |
thanks ;) |
| [10:15:39] |
<jborg> |
I also like that it cleans up the "req, db" mess on some places. |
| [10:16:21] |
<cboos> |
yes, but I've been very cautious about that, (i.e. to not do it more than needed) |
| [10:16:36] |
<jborg> |
In the future I would like to see Trac use a single db transaction for the entire request. |
| [10:16:45] |
<jborg> |
But I'm not sure what performance impact that will have on sqlite |
| [10:17:20] |
<cboos> |
that's ok, as long as _cursors_ are not left with a running query |
| [10:17:46] |
<cboos> |
i.e. what's bad is iterating on a select, then inside the iteration, do some heavy stuff. |
| [10:18:00] |
<cboos> |
that's not even bad, that's catastrophic for sqlite ;) |
| [10:18:25] |
<jborg> |
heh |
| [10:18:35] |
<cboos> |
but other than that, keeping the same connection is ok (and this is what already happens btw) |
| [10:19:07] |
<cboos> |
Since the postgresql switch, I'm not sure if you had the opportunity to try out how well Trac now behaves wr.t. to the database is locked issue... |
| [10:19:27] |
<cboos> |
i.e. for me the problem is solved ... though I don't fully understand why ;) |
| [10:19:27] |
* |
OdCp|sir0n has joined #trac |
| [10:19:38] |
<OdCp|sir0n> |
hello |
| [10:19:49] |
<jborg> |
It would be really nice to have "atomic" requests. |
| [10:19:55] |
<OdCp|sir0n> |
can i get support for phpchrystal here ? |
| [10:20:03] |
<cboos> |
OdCp|sir0n: no |
| [10:20:22] |
<OdCp|sir0n> |
hmm |
| [10:20:25] |
<cboos> |
(but you can stay we don't kick you for having asked ;) ) |
| [10:20:26] |
<OdCp|sir0n> |
u know where ? |
| [10:20:27] |
<jborg> |
And once we have solid mysql+pgsql we might get away with "only" supporting sqlite for low-traffic sites |
| [10:21:04] |
<cboos> |
well, I'd be curious to see how well sqlite would be on a site like t.e.o, I'm quite sure it would be ok now |
| [10:22:21] |
<cboos> |
(i.e on test, I was constantly triggering like 50 complex simultaneous requests, and never got a lock; but ok that was tracd on windows, so maybe it's not completely transposable to same with apache prefork) |
| [10:23:22] |
<jborg> |
As far as I know sqlite3 has better concurrency support in threaded mode. |
| [10:24:08] |
<jborg> |
btw, do you get two copies on all t.e.o notifications if you are the ticket owner? |
| [10:24:38] |
<cboos> |
not even if I'm owner, for all my updates I get two mails. |
| [10:25:45] |
<jborg> |
oh, any active ticket about that? |
| [10:25:46] |
<cboos> |
but that's probably because I get one from the mailing list, and the other one because of the notify updater, no? |
| [10:25:59] |
<jborg> |
yeah, that might be it |
| [10:26:17] |
* |
idnar_ is now known as idnar |
| [10:26:23] |
<jborg> |
I guess there is nothing we can do about that. |
| [10:27:21] |
<jborg> |
unless we add all addresses from the mailing-list to the "always_notify" option. |
| [10:29:41] |
* |
cboos_ has joined #trac |
| [10:30:22] |
<mitsuhiko> |
wtf is phpchrystal? |
| [10:30:33] |
* |
cboos_ is back |
| [10:30:38] |
<mitsuhiko> |
wb cboos_ |
| [10:30:48] |
* |
flox has quit IRC |
| [10:31:14] |
<mitsuhiko> |
cboos_: what about setting the default logo href to "/"? |
| [10:31:31] |
<mitsuhiko> |
i hate it when i try to click on the logo of $RANDOMTRAC and get redirected to example.com ;) |
| [10:32:19] |
<cboos_> |
ah, coincidentally, in the WikiContext patch, I fixed the documentation for [project] url |
| [10:33:02] |
<cboos_> |
as it's actually used (besides the logo) for determining if an http link is external or has to be shown as a local one... |
| [10:33:23] |
<cboos_> |
see Context.local_url() |
| [10:33:26] |
* |
flox has joined #trac |
| [10:34:36] |
* |
cboos has quit IRC |
| [10:34:43] |
<cboos_> |
say you have a http://example.org/trac site, then if "[project] url" is set to example.org, then all the links starting with that will be shown as local links |
| [10:34:45] |
* |
cboos_ is now known as cboos |
| [10:35:28] |
<cboos> |
(and yes, I've also removed that 'example.org' from the default ;) ) |
| [10:37:13] |
* |
OdCp|sir0n has quit IRC |
| [10:42:30] |
<cboos> |
any english speaker writer here? |
| [10:42:50] |
<cboos> |
should I write "cmlenz' suggestion" or "cmlenz's suggestion" ? |
| [10:43:01] |
<idnar> |
cmlenz's |
| [10:43:13] |
<cboos> |
thanks! |
| [10:43:25] |
<idnar> |
as far as I know, the modern convention is to always include the trailing 's', even if the name itself ends with 's' |
| [10:43:44] |
* |
hotte has joined #trac |
| [10:43:48] |
<cboos> |
really? as in cboos's next great idea? ;) |
| [10:44:01] |
<idnar> |
yeah |
| [10:44:06] |
<cboos> |
looks weird... I've been used to the standalone ' |
| [10:44:19] |
* |
s0undt3ch has quit IRC |
| [10:44:20] |
* |
pygi has joined #trac |
| [10:44:21] |
* |
s0undt3ch has joined #trac |
| [10:44:25] |
<pygi> |
prologic: ping |
| [10:44:27] |
<pygi> |
prologic: ping |
| [10:44:38] |
<idnar> |
cboos: I think that form was previously in use |
| [10:46:43] |
* |
pygi has left #trac |
| [10:50:34] |
* |
flox has quit IRC |
| [10:52:11] |
<mitsuhiko> |
cboos: from where are you? |
| [10:52:50] |
<cboos> |
from France (Strasbourg -> Lingolsheim to be precise) |
| [10:53:07] |
<mitsuhiko> |
ah |
| [10:58:05] |
<cboos> |
ok, the browser-quickjump branch seems ready to go ... |
| [10:58:15] |
<cboos> |
jborg, do you have some more comments on the WikiContext? |
| [11:16:45] |
<jborg> |
cboos, not really, but to keep everybody up to date I guess it wouldn't hurt to at least send a mail to trac-dev with a link to the wiki page. |
| [11:17:10] |
<cboos> |
well, I wanted to commit this evening ... |
| [11:18:19] |
<cboos> |
now that I have your ear, are you +1 for the GenericTrac branch (or branches), as presented on the trac-dev Mailing List ? |
| [11:18:21] |
<jborg> |
ok, but you can still commit it now if you want to |
| [11:19:14] |
<jborg> |
You mean the DataModel / Journaling thing? |
| [11:19:21] |
<cboos> |
right |
| [11:19:36] |
<cboos> |
and starting with the milestone as a way to illustrate / validate the concepts |
| [11:20:47] |
<cboos> |
right now I'm about to mergre the browser-quickjump branch to make some room in /sandbox ;) |
| [11:20:58] |
<cboos> |
... turned out the merge was extra painfull -> the About.py / about.py rename broke my working copy :( |
| [11:21:13] |
<jborg> |
I've not given it a lot of thought but my gut feeling is that it sound a bit complex and scary, but I don't mind your evaluating it in the sandbox |
| [11:21:38] |
<jborg> |
s/your/you/ |
| [11:21:47] |
<cboos> |
well, I bet that complex and scary is what will look the current trac in retrospect, we'll see ;) |
| [11:22:18] |
<cboos> |
thanks for the +1 ;) |
| [11:25:28] |
<jborg> |
Sure, I dont' see any need to limit the number of sandbox branches. Event things like the WikiContext should IMHO go into a branch. |
| [11:26:16] |
<cboos> |
well, then we have to distinguish the working branches form the "official" ones |
| [11:26:22] |
<jborg> |
But then we probably need to change our branch mering policy. There should be no need for voting if the branch is small enough |
| [11:26:40] |
<cboos> |
right, I would have created a wiki-context branch if the "procedure" wasn't so scary |
| [11:27:43] |
<jborg> |
ok, then that is something we'll need to address... |
| [11:29:49] |
<cboos> |
look at the upcoming changeset, which will be the integration of the browser-quickjump, that's pretty small. Though I took the route of a branch, with a mail for its creation (ok, that was bypassed because that was part of the VcRefactoring which has already been discussed in the past) and request for comments, and request for approval, and ... |
| [11:30:53] |
<cboos> |
but in the end, it was a pretty small change, which finally took 2 months (!) for reaching the trunk |
| [11:31:23] |
<cboos> |
that was more or less OK for me, as that was a focused change that didn't affect the rest |
| [11:32:29] |
<cboos> |
but for something like the wiki-context, I'd really hate to see that work sit in a branch for 2 months, ... that would be 1/ highly demotivating 2/ prevent any reuse of those changes to fix further related issues or to simply build up on this. |
| [11:34:01] |
<jborg> |
Yeah, that's unfortunate. We need a more streamlined way to handle smaller branches. |
| [11:34:54] |
<jborg> |
Replacing the voting with a simple "presentation of the branch" on the list, and if nobody objects within a few days the author should be free to commit the change. |
| [11:35:43] |
<jborg> |
In the WikiContext case it would be enough to link to the diff and the corresponding wiki page. |
| [11:36:15] |
<cboos> |
that would be ok, yes |
| [11:36:19] |
<jborg> |
So even if there is no reactive it's ok to commit after a few days |
| [11:36:29] |
<jborg> |
s/reactive/reaction/ |
| [11:36:48] |
<cboos> |
so I propose to try out that approach with wiki-context, to see how well it works |
| [11:37:49] |
<jborg> |
That's a good idea. That way it's easier to stay updated even if you don't have time to monitor all tickets |
| [11:42:34] |
<cboos> |
Ok, jonas there's another "branch policy" that I'm a bit incomfortable with ... it's the "don't branch on branches" one. While I agree it's not a good thing to do in general, this will hurt me for the GenericTrac thing. |
| [11:43:06] |
<cboos> |
I'd like to get the GenericTrac do some work on the milestone adopting the new datamodel, |
| [11:43:53] |
<cboos> |
then I'd like to show how this could extend to other areas, but for clarity, I don't want to put all changes in the same branch. |
| [11:44:18] |
<cboos> |
e.g. /sandbox/generic-trac/milestone-refactoring -> the starting point |
| [11:44:56] |
<cboos> |
e.g. /sandbox/generic-trac/ticket-refactoring -> see how well the new model adapts to the ticket system, reuse the infrastructure done in the /sandbox/generic-trac/milestone-refactoring branch |
| [11:45:27] |
<cboos> |
then /sandbox/generic-trac/wiki-refactoring -> adapt to the wiki system, also reuses the infrastructure from the /sandbox/generic-trac/milestone-refactoring branch |
| [11:46:36] |
<cboos> |
... and of course, the trac-xref branch that I'd like to transform in a plugin, but this needs a trac that has been modified to the new model as well |
| [11:48:03] |
<jborg> |
well, it's never simple to have long-lived branches. |
| [11:48:17] |
<cboos> |
... that's all we have ;) |
| [11:49:11] |
<cboos> |
plus, the workflow branch could probably be wiped out for now (maybe even resurrect the old one), as it's currently a plain copy of the trunk |
| [11:49:29] |
<jborg> |
Another option is to first show that the concept holds for a simple case (milestones perhaps) and then add a more complex module (tickets perhaps). After that the whole thing could be evaluated for merge with trunk |
| [11:49:45] |
<cboos> |
ah that would be great! |
| [11:50:05] |
<jborg> |
as a single branch |
| [11:50:18] |
<cboos> |
ok, I'm all for it |
| [11:50:34] |
<cboos> |
let that be /sandbox/generic-trac |
| [11:51:07] |
<cboos> |
as I've already prepared the "roadmap" for it: |
| [11:51:11] |
<cboos> |
@wiki GenericTrac |
| [11:51:11] |
<evil_twin> |
cboos: http://trac.edgewall.org/wiki/GenericTrac |
| [11:55:09] |
<jborg> |
ok, got to go now, bbl. |
| [11:55:11] |
* |
jborg has quit IRC |
| [11:57:17] |
* |
GarethTheGreat has joined #trac |
| [11:57:25] |
<GarethTheGreat> |
hi |
| [11:58:02] |
<GarethTheGreat> |
anyone know if authenticating trac users via an arbitary MySQL table (used for authentication on the rest of my site) is possible? |
| [12:03:41] |
<cboos> |
TracAuthDbPlugin on trac-hacks? |
| [12:03:53] |
<cboos> |
(not sure about the exact name, though) |
| [12:10:09] |
* |
FFighter has joined #trac |
| [12:10:11] |
<FFighter> |
hello |
| [12:10:19] |
<GarethTheGreat> |
can't find anything like that |
| [12:10:34] |
<GarethTheGreat> |
could i use the AccountManagerPlugin to do the job? |
| [12:10:49] |
<GarethTheGreat> |
or does it still require user lookups in Trac's own users database? |
| [12:11:26] |
<GarethTheGreat> |
basically i have a users table for the rest of my site (forums, chatroom, wiki etc) and want to have support tickets issued by users without a seperate trac login |
| [12:12:39] |
<cboos> |
http://trac-hacks.org/wiki/DbAuthPlugin |
| [12:15:11] |
<FFighter> |
Has anyone ever had problems on commiting large changeset and getting "Can't write to connection" errros? |
| [12:15:26] |
<GarethTheGreat> |
cboos: got it |
| [12:16:33] |
<FFighter> |
I'm using svnserve |
| [12:22:34] |
<mitsuhiko> |
WOA |
| [12:22:43] |
<mitsuhiko> |
anyone checked out the recent firebug beta? |
| [12:22:46] |
<mitsuhiko> |
holy fuck |
| [12:22:58] |
<mitsuhiko> |
that's clearly the best webdeveloper tool ever created |
| [12:23:38] |
<FFighter> |
mitsuhiko: Hmm, interesting.. what's that about ? |
| [12:23:55] |
<mitsuhiko> |
FFighter: www.getfirebug.com and have a look at the screenshots |
| [12:24:09] |
<mitsuhiko> |
but the best is trying it out yourself |
| [12:24:21] |
<mitsuhiko> |
it's hard to explain what that extension really allows you to do Oo |
| [12:24:28] |
<mitsuhiko> |
i'm really impressed |
| [12:24:54] |
<FFighter> |
mitsuhiko: Something like the webdeveloper toolbar ? |
| [12:25:20] |
<FFighter> |
holy shit LOL |
| [12:25:25] |
<FFighter> |
seems powerful |
| [12:25:43] |
<FFighter> |
and best of all, its OS |
| [12:26:08] |
<mitsuhiko> |
jep |
| [12:28:39] |
* |
gak has joined #trac |
| [12:29:11] |
* |
detritus_ has joined #trac |
| [12:29:17] |
<detritus_> |
allo |
| [12:29:57] |
<detritus_> |
unsurprisingly, I could do with a bit of help |
| [12:29:59] |
<detritus_> |
anyone around? |
| [12:37:38] |
* |
gakman has quit IRC |
| [12:38:51] |
* |
FFighter has quit IRC |
| [12:46:40] |
* |
lightcap has joined #trac |
| [13:02:49] |
* |
detritus_ has quit IRC |
| [13:11:06] |
* |
flox has joined #trac |
| [13:13:34] |
* |
omry has quit IRC |
| [13:16:19] |
* |
cboos has quit IRC |
| [13:19:46] |
* |
gummibaerchen has joined #trac |
| [13:50:46] |
* |
hotte has quit IRC |
| [13:59:36] |
* |
bryanl has joined #trac |
| [14:05:48] |
* |
m_g has quit IRC |
| [14:10:09] |
* |
lasindi has joined #trac |
| [14:11:06] |
* |
gummibaerchen has quit IRC |
| [14:12:33] |
<lasindi> |
Hi everyone, I'm trying to set up a trac server with the tracd daemon, and it appears to work except that I cannot get authentication working. I've set up a file /var/www/trac/trac.htpasswd and passed it with the --basic-auth option on my tracd call; any ideas for what I'm doing wrong? |
| [14:16:57] |
* |
matt_good has quit IRC |
| [14:22:33] |
* |
chtito has quit IRC |
| [14:35:48] |
* |
Jasper^ has joined #trac |
| [14:40:34] |
* |
Jasper^ has quit IRC |
| [14:52:41] |
* |
coderanger has joined #trac |
| [14:56:29] |
* |
sabi has left #trac |
| [14:59:49] |
* |
matt_good has joined #trac |
| [15:06:30] |
* |
whitelynx has quit IRC |
| [15:24:35] |
* |
bryanl has quit IRC |
| [15:26:23] |
* |
omry has joined #trac |
| [15:46:37] |
* |
matt_good has quit IRC |
| [15:55:39] |
* |
Guychi has joined #trac |
| [15:56:01] |
<Guychi> |
Good evening. How can I increase the height of the description editing field? |
| [15:57:10] |
<coderanger> |
Just edit the template |
| [16:36:04] |
* |
Guychi has quit IRC |
| [16:44:17] |
* |
demianturner has left #trac |
| [16:48:39] |
* |
tpollari has joined #trac |
| [16:49:28] |
* |
matt_good has joined #trac |
| [16:51:09] |
* |
flox has quit IRC |
| [16:55:11] |
<matt_good> |
ok, I'm back |
| [16:55:17] |
* |
jannek_ has joined #trac |
| [16:55:36] |
<matt_good> |
so, now does anyone know how to use ToscaWidgets to define a dynamic <select> list field? |
| [16:58:42] |
* |
Jeena_ has joined #trac |
| [16:59:55] |
<Jeena_> |
Hi, how do I add two new items to the mainnav? |
| [17:01:11] |
<matt_good> |
doh, ignore my comments, that was meant for #turbogears :( |
| [17:01:41] |
<coderanger> |
Jeena_: What kind of items |
| [17:02:25] |
<Jeena_> |
a linkt to blog and a link to demo like on this page: http://jeenaparadies.net/projects/jlog/blog/ |
| [17:02:38] |
<coderanger> |
tractabs or navadd |
| [17:03:04] |
<Jeena_> |
is there a documentation? |
| [17:03:19] |
<matt_good> |
Jeena_: they're plugins on trac-hacks.org |
| [17:03:27] |
* |
jannek has quit IRC |
| [17:03:37] |
<Jeena_> |
ah ok |
| [17:07:03] |
* |
Tetraboy has quit IRC |
| [17:08:23] |
* |
bryanl has joined #trac |
| [17:10:03] |
* |
bryanl has quit IRC |
| [17:11:51] |
* |
hobu has joined #trac |
| [17:21:14] |
<hobu> |
anyone have any experience proxying Trac? I have Trac running on a mod_python Apache2 instance (on port 81), which is being proxied to b |
