[Trac-dev] Re: Trac Development to support Change and Requirements Management

Hello Christopher,

> A custom field that has the source of the bug would work for this ....
> you could then specify
> source:/trunk/componentname/classfiled <at> <revision>#L<linenumber>
> and then you could write a report for them that takes as input a path
> and then searches for all tickets whose aforementioned custom field
> begins with the input path
>   
Thanks for the tip, I will try this out. Possibly this can be done 
automatically with a post-commit hook script??? Need to think about this 
a little further.

> not sure how a hook script can help you here .... you need to know
> what lines of code the bug was *found* in.  However, this would deff
> help you determine what lines of code were modified to fix a bug .....
>   
I thought about parsing a commit message like "fixd bug #xxx introduced 
in [1234]" and that together with the checkin path this will 
automatically combine the revision with the ticket.

> to me that sounds more like a policy issue than a trac issue.  A
> suggestion if I may ... use the version number to determine what
> version the bug was found in (could be N/A for an anhancement) and
> assign it against the milestone for trunk (or the maintenance of a
> released version if that's a higher priority for you .... just pick
> one and be consistent).  
That is what we currently do. But it still has the problem, that we can 
not tell which bug exist in which version. E.g. if you find a bug in the 

[Trac-dev] Trouble with macros

Hello all,

I'm having trouble hunting down a bug within a Macro.

The issue is that I'm trying to use the WikiInclude macro to include a
page that calls the ParentLinkage macro.  The problem is that the
ParentLinkage macro calls the wiki_to_html method but does not have a
request object to pass in .... this later causes ParentLinkage to bomb
 (I think this basically happens because the macro system only knows
about requests, and the macros are not called with a request, only
with an hdf object)   I was wondering if there is a way that if the
macro retrieve the req object that contains the hdf object?

-Chris

--~--~---------~--~----~------------~-------~--~----~
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: Trouble with macros

Well, the IncludeMacro installed as a plugin works a lot better .....I
guess that's the benefit of  writing this as a plugin as opposed to a
macro.

however, the ParentLinkage Macro now displays the for the containing
wiki, not the contained wiki.  I think this issue is that the
IncludeMacro doesn't give other macros inside of the included wiki a
chance to run in their own 'scope' .... I'll submit a patch shortly.

-Chris

On 7/3/07, Christopher Taylor <chtaylo3 <at> gmail.com> wrote:
> Hello all,
>
> I'm having trouble hunting down a bug within a Macro.
>
> The issue is that I'm trying to use the WikiInclude macro to include a
> page that calls the ParentLinkage macro.  The problem is that the
> ParentLinkage macro calls the wiki_to_html method but does not have a
> request object to pass in .... this later causes ParentLinkage to bomb
>  (I think this basically happens because the macro system only knows
> about requests, and the macros are not called with a request, only
> with an hdf object)   I was wondering if there is a way that if the
> macro retrieve the req object that contains the hdf object?
>
> -Chris
>

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

[Trac-dev] Re: On base_url case...

I'd like to resume this thread that has been forgotten, as I think the
"base url", python uri root and the like should be simplified before
0.11 is delivered.

The documentation may need to be updated so that
the base URL appears to be the single, unique location (base_url in
trac.ini). No more "UriRoot" option in Apache, for instance.

Moreover, I'm not a big fan to hard code the base url in the trac.ini
file. At least, the "server" part of the URL.

The rationale is that it prevents Trac from being served from several
server names, for example an installation with http://localhost,
http://a.b.c.c and http://server need to use three different Trac
engine to server the same environment, which is a bit overkill. This,
in turn, force the use of syslog for the error logger, if all the
messages are to be sent to the same file whatever the server name used
to access Trac.

I understand though that Trac needs to know its own URL, for example
when a notification is triggered from a hook script, Trac needs to
know the URL and it can't get it from a web request.

However, would it be possible to split the base_url option into the
server part (which is required for the notification) and the base path
part (which cannot be guessed right from the client requests, if I my
understanding is correct) ?

Is the "server" part of base_url required for anything else than the

[Trac-dev] Re: On base_url case...

Alec and I discussed this a while ago, but I guess neither of us has had
time to implement it. The procedure to isolating req.base_path should be
 1. Look for a WSGI variable trac.base_url (possibly from SetEnv
TRAC_BASE_URL or PythonOption TracBaseUrl).
 2. Look at base_url in trac.ini.
 3. Guess from the request (not an option always).

I think this covers all the use cases quite cleanly, and would greatly
simplify the deployment of Trac on DreamHost-style shared servers.

--Noah

Emmanuel Blot wrote:
> I'd like to resume this thread that has been forgotten, as I think the
> "base url", python uri root and the like should be simplified before
> 0.11 is delivered.
> 
> The documentation may need to be updated so that
> the base URL appears to be the single, unique location (base_url in
> trac.ini). No more "UriRoot" option in Apache, for instance.
> 
> Moreover, I'm not a big fan to hard code the base url in the trac.ini
> file. At least, the "server" part of the URL.
> 
> The rationale is that it prevents Trac from being served from several
> server names, for example an installation with http://localhost,
> http://a.b.c.c and http://server need to use three different Trac
> engine to server the same environment, which is a bit overkill. This,
> in turn, force the use of syslog for the error logger, if all the
> messages are to be sent to the same file whatever the server name used

[Trac-dev] Re: On base_url case...

Emmanuel Blot wrote:
> I'd like to resume this thread that has been forgotten, as I think the
> "base url", python uri root and the like should be simplified before
> 0.11 is delivered.
>
> The documentation may need to be updated so that
> the base URL appears to be the single, unique location (base_url in
> trac.ini). No more "UriRoot" option in Apache, for instance.
>
> Moreover, I'm not a big fan to hard code the base url in the trac.ini
> file. At least, the "server" part of the URL.
>
> The rationale is that it prevents Trac from being served from several
> server names, for example an installation with http://localhost,
> http://a.b.c.c and http://server need to use three different Trac
> engine to server the same environment, which is a bit overkill. This,
> in turn, force the use of syslog for the error logger, if all the
> messages are to be sent to the same file whatever the server name used
> to access Trac.
>
> I understand though that Trac needs to know its own URL, for example
> when a notification is triggered from a hook script, Trac needs to
> know the URL and it can't get it from a web request.
>
> However, would it be possible to split the base_url option into the
> server part (which is required for the notification) and the base path
> part (which cannot be guessed right from the client requests, if I my
> understanding is correct) ?
>

[Trac-dev] Re: Hacking Milestones

On Jun 28, 7:22 am, "Christopher Taylor" <chtay... <at> gmail.com> wrote:
> In version 0.10.4, I'm editing  the milestone schema to contain a
> priority (same as tickets) however I'm having trouble figuring out the
> interactions b/n html,ClearSilver, and Python.  I've got the drop down
> box displaying for the user to select the priority however, I'm having
> trouble getting that selection to propegate up to the python code.
> Can someone please point me in the right direction.

Well, I might try to follow up on the main question later, but as a
quick post before I got to bed:
Don't hack the Trac tables.  If you need to augment the data in a Trac
table it's better to create a new table keyed off the same values as
the table you're augmenting.  Due to SQLite's limited support for
ALTER TABLE Trac's upgrades blow away the existing table and copy the
data into the new schema, so any changes you make to Trac's built-in
tables will be lost.

-- Matt

--~--~---------~--~----~------------~-------~--~----~
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] Pygments wiki processors in Trac

A user reported an issue with #!rst being broken as a wiki processor
after installing the 0.10 version of Pygments.  I looked and the 0.10
version registers a wiki processor for each shortname which causes the
issue with rst.  This behavior is not in trunk, and is not currently
configurable.

I'd like to get some further input on the topic of how this should be
configurable.  Noah suggested a blacklist for shortnames that you
don't want to be usable in this way, which I'm okay with but want to
make sure that we make it as similar as possible between the 0.10
plugin and what's in 0.11-dev.

I think the syntax we talked about was something like

[mimeviewer]
pygments_nomacros = rst,apacheconf

Any thoughts? Is this a good thing, and of so should we want to both
port the wiki processor code from the 0.10 plugin to 0.11 and add
configurability to both?  Should 'rst' be the default value if the
property is unset, or should it be nothing blacklisted?

Tim

--~--~---------~--~----~------------~-------~--~----~
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: Pygments wiki processors in Trac

Tim Hatch wrote:
> A user reported an issue with #!rst being broken as a wiki processor
> after installing the 0.10 version of Pygments.  I looked and the 0.10
> version registers a wiki processor for each shortname which causes the
> issue with rst.  This behavior is not in trunk, and is not currently
> configurable.
> 
> I'd like to get some further input on the topic of how this should be
> configurable.  Noah suggested a blacklist for shortnames that you
> don't want to be usable in this way, which I'm okay with but want to
> make sure that we make it as similar as possible between the 0.10
> plugin and what's in 0.11-dev.
> 
> I think the syntax we talked about was something like
> 
> [mimeviewer]
> pygments_nomacros = rst,apacheconf
> 
> Any thoughts? Is this a good thing, and of so should we want to both
> port the wiki processor code from the 0.10 plugin to 0.11 and add
> configurability to both?  Should 'rst' be the default value if the
> property is unset, or should it be nothing blacklisted?

As I said online, there is a far more general solution. All that we need
is to allow mimeview processors to add to the mime_map, possibly with a
weighting. Right now that map is generated from a hardcoded list, and
the contents of mime_map in trac.ini, so I think allowing plugins to
directly contribute would make sense.

--Noah

[Trac-dev] using trac for code documentation