[Trac-dev] Re: A Christmas gift - TicketDep plugin

On Dec 24 2008, 2:36 pm, Risto Kankkunen <risto.kankku... <at> gmail.com>
wrote:
> Our team uses Trac to manage our sprint backlogs. We find it useful to
> split bigger tasks into subtasks and use MasterTicketsPlugin to track
> the dependencies. However, it is currently not easy to see those
> dependencies. The Graphviz diagrams require effort to see and are not
> even very informative.
>
> I made a plugin calledTicketDepthat shows the dependencies as
> indented tables. After using the plugin for some time I find that it
> helps to see the context of a particular ticket and also makes it
> easier to find the right parent for new subtickets. The plugin is
> available in
>
>  http://iki.fi/risto.kankkunen/trac/ticketdep
>
> I'd like to hear if people find this useful and if someone has already
> done something similar.

could you maybe put the source code so one could do an easy_install
with it in a python-2.5 environment?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] contrib/trac-post-commit-hook vs. SvnChangeListener vs. RepositoryHookSystem

Hi,

This is somewhat in reply to
http://groups.google.com/group/trac-dev/browse_thread/thread/ded9c142e6fb54c1/072484b41c5f6f60 .

There has been some talk on the trac channel about removing the exist trac-post-commit-hook and replacing
it with one of my pluggable solutions:

 * http://trac-hacks.org/wiki/SvnChangeListenerPlugin : works only with SVN's post commit hook

 * http://trac-hacks.org/wiki/RepositoryHookSystemPlugin : architected for arbitrary
repositories, though currently only implemented for SVN

The idea is the contributed script is not pluggable and actually does two unrelated things:

 1. gets a changeset from a commit
 2. uses the changeset message to close tickets

The above plugins separate this functionality and makes it pluggable.

Is there any thought about pro vs. con and how to do this (assuming pro)?  I recommend the
RepositoryHookSystem, even though it is less tested, as (IMHO) it should cover all use-cases while of
course SvnChangeListener only works for SVN.

I'd be glad to work on a branch and port to trunk but, since its a plugin, I'm not sure what should actually go in
the branch.  I could add the whole plugin.  That would be the simplest.  But I'm not sure if this meets with
trac's philosophy.

Thoughts?

[Trac-dev] Re: contrib/trac-post-commit-hook vs. SvnChangeListener vs. RepositoryHookSystem

Jeff Hammel wrote:
> Is there any thought about pro vs. con and how to do this
> (assuming pro)?

I have implemented a post-commit listener interface
IRepositoryChangeListener in the multirepos branch, as part of:

  http://trac.edgewall.org/ticket/7723

The notification is triggered by a "trac-admin repository changeset"
command, which should be called for every changeset that is added to a
repository, typically from a post-commit hook.

I knew about the SvnChangeListenerPlugin, but not about
RepositoryHookSystemPlugin, and I only implemented the post-commit
event. The interface could be extended, though.

The patch is waiting for review from Christian Boos, as he's the owner
of the multirepos branch.

-- Remy

[Trac-dev] Re: contrib/trac-post-commit-hook vs. SvnChangeListener vs. RepositoryHookSystem

On Jan 2, 2009, at 5:20 PM, Remy Blank wrote:

> Jeff Hammel wrote:
>> Is there any thought about pro vs. con and how to do this
>> (assuming pro)?
>
> I have implemented a post-commit listener interface
> IRepositoryChangeListener in the multirepos branch, as part of:
>
>  http://trac.edgewall.org/ticket/7723
>
> The notification is triggered by a "trac-admin repository changeset"
> command, which should be called for every changeset that is added to a
> repository, typically from a post-commit hook.
>
> I knew about the SvnChangeListenerPlugin, but not about
> RepositoryHookSystemPlugin, and I only implemented the post-commit
> event. The interface could be extended, though.
>
> The patch is waiting for review from Christian Boos, as he's the owner
> of the multirepos branch.

Perhaps that is what I remembered then. I was talking to Jeff on the  
IRC channel and had a vague memory that we had been looking at adding  
something like this to core.

--Noah

--~--~---------~--~----~------------~-------~--~----~

[Trac-dev] mod_python --> mod_wsgi: handler chain?

what would be the best way to migrate from mod_python to mod_wsgi?
with mod_python we just chained handlers in the apache config to strip
off additional info from the user-name. how one would do this with
mod_wsgi?

<Location /projects>
  SetHandler mod_python
  PythonInterpreter main_interpreter
  PythonHandler trac.web.myuserhandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /opt/csw/apache2/trac
  PythonDebug On
  PythonOption TracLocale ro_RO
  SetEnv PYTHON_EGG_CACHE /tmp/cache/trac-eggs
</Location>

myuserhandler.py is just 2 lines to strip the user:
import string
from mod_python import apache
def handler(req):
   if req.user!=None:
       req.user=req.user[0:req.user.find('(')-1]
   return apache.OK

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: mod_python --> mod_wsgi: handler chain?

You could alter the WSGI script to run a similar bit of code (altering  
environ['REMOTE_USER'] instead) if you wanted. Just check out the WSGI  
API spec, it is pretty simply. You could also make a plugin  
subclassing LoginModule and handle this in Trac itself.

--Noah

On Jan 3, 2009, at 11:22 AM, rupert.thurner <at> gmail.com wrote:

>
> what would be the best way to migrate from mod_python to mod_wsgi?
> with mod_python we just chained handlers in the apache config to strip
> off additional info from the user-name. how one would do this with
> mod_wsgi?
>
> <Location /projects>
>  SetHandler mod_python
>  PythonInterpreter main_interpreter
>  PythonHandler trac.web.myuserhandler trac.web.modpython_frontend
>  PythonOption TracEnvParentDir /opt/csw/apache2/trac
>  PythonDebug On
>  PythonOption TracLocale ro_RO
>  SetEnv PYTHON_EGG_CACHE /tmp/cache/trac-eggs
> </Location>
>
> myuserhandler.py is just 2 lines to strip the user:
> import string
> from mod_python import apache
> def handler(req):

[Trac-dev] Need to put to list values in a single list

Hi All,
I have one basic doubt in python how do we put two differnt list
values in a single list ..

Thanks&Regards
vela.velappan

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: Need to put to list values in a single list

> I have one basic doubt in python how do we put two differnt list
> values in a single list ..

a.extend(b) ?

Anyway, this is not related to Trac, so please refrain from posting
off-topic messages to Trac mailing lists.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Trac-dev] Re: More Runaway Trac Process

on Tue Dec 30 2008, Christian Boos <cboos-AT-neuf.fr> wrote:

> David Abrahams wrote:
>> on Sat Dec 27 2008, David Abrahams <dave-AT-boostpro.com> wrote:
>>
>>   
>>>> -On [20080617 22:20], David Abrahams (dave <at> boostpro.com) wrote:
>>>>       
>>>>> #0  0x000000080098b85c in pthread_testcancel () from /lib/libpthread.so.2
>>>>> #1  0x0000000800982de7 in pthread_mutexattr_init () from /lib/libpthread.so.2
>>>>> #2  0x00000008009849cb in pthread_mutexattr_init () from /lib/libpthread.so.2
>>>>> #3  0x000000080098799f in pthread_setconcurrency () from /lib/libpthread.so.2
>>>>>         
>>>> Last time I mentioned a possible threading/python issue on FreeBSD I got
>>>> told on the Python list that FreeBSD's threading has caused issues for
>>>> Python before. Now, whether or not this is a problem within FreeBSD or
>>>> simply something else (read: Python itself), I cannot say.
>>>>       
>>> Here's another stack backtrace of a Trac process taking 100% CPU.  It's
>>> a good thing the server has two cores 
>>>
>>> I realize this seems to implicate FreeBSD threading, but this doesn't
>>> happen to my Django processes, for example, so I'm still a little
>>> inclined to suspect Trac.  I have a hunch that these runaway processes
>>> start when I ask for something that takes a long time from Trac, like an
>>> old changeset, but then get impatient and cancel the request.  Is that
>>> possible?
>>>     
>>

[Trac-dev] Full-text search of attachments to Trac Wiki pages?