Flyspray - The bug killer!

I ‘ll be specially interested to see a SVN integration plugin, you code looks ok so far, we may (kim not telling we should) add something like this for 1.0.

go ahead if you want to provide tested, documented code.

Your class is for php5, which is fine for me, for 1.0 we can just add php5 only features, we need to start killing PHP4 anyway.

Well, I’d say PHP5 only if it has significant advantages over the corresponding PHP4 code. 1.0 is not yet the right time for PHP5 only. And yes, SVN would be more important since we use it ourselves and it is more current than CVS.

Ideas for better integration:

• auto close tasks if they are mentioned in the commit message
• in the revision list, link to related tasks
• cache data with schedule.php so that there is no delay (if repository is remote)
• show related commits on the tasks page

auto close tasks if they are mentioned in the commit message – it would be ok, if the user is allowed to decide about autoclosing. Sometimes several commits are related to a single task. Par example, I could write comments in the tasks for each commit in such cases.

This is definately something we’re looking for. I’ve got a plan for doing it with a cheap wrapper, myself, but it would be much better if it’s built into the system.

As for auto-closing tasks, I’d recommend doing something like Debians BTS. If the change log has ‘Closes #1234’ bug #1234 is closed. And if you have something like ‘Closes #1234,#1235,#2235’ all those bugs get closed. I’d love to have that functionality.

As for PHP4 vs PHP5, we’re currently still running PHP4 and will be until we can get our current project migrated to PHP5, as well as ensuring all the PHP apps we have work with it. So, I for one, would vote for keeping PHP4 support for now.

So, I for one, would vote for keeping PHP4 support for now.

And we’ll do, at least for 1.0.

I for one, would vote for keeping PHP4 support for now.

There are no plans to change the basic requirements for flyspray version 1.0, however we may move to PHP5 after 1.0 ( you may need to move to PHP5 anyway as it will be going out of support...)

Hi,

I would like to have the same syntax parsing that is used in the comments and descriptions.

About closing tasks, I think that this could be done in another way. I would prefer to implement the XML/RPC interface and then implement a hook for SVN to close the task on the post_commit hook. I would implement the following things:

1- /close|fixed|done FS#\d/ → closes the task 2- /comment|see FS#\d/ → adiciona comment

Other things like this could be done.

The reason why I would implement this in the post_commit hook and not in the browsing is because that way it would be done one once, when the commit to the SVN as completed.

The reason why I would do this with XML/RPC is because this would allow the creation of other tools, like mail to flyspray.

The Mage

Problem is that we don’t have any XML-RPC and if no one else takes care of it (we are busy already) it won’t be there any time soon.

I noticed that already. I would say that I will implement that because I don’t know the flyspray sources, but I’ll look at the sources, and if I can manage to do it I will joyfully take care of that, because I see a lot of useful things I would do with it.

What I was intenting to say was that I wouldn’t say that I will implement it yet.

I would love to see the SVN and CVS integration in 1.0.x

FYI: There’s already a possibility to include SVN-Info when using WebSVN as a front-end. This can be done using the DokuWiki syntax instead of plain-text in conjunction with a DokuWiki Plugin named surprisingly WebSVN.

Using this DokuWiki Plugin you can include direct links to files within a SVN-repo. It also has the ability to show the file(s) iframe-inlined. This way the related files can be showed directly from the SVN-repo within FlySpray Task Descriptions/Comments...

I’m aware that this isn’t completely the meaning of this FS-task, but maybe it’s something usable for some ppl...

SVN support is already done in 1.0, only the hooks are missing.

SVN support will be really nice

yes this is some to be good and maybe some thing like this for "git" if it can be done.

test

In version 0.9.8, I had changed the function includes/functions.inc.php::formatText() to change "SVN#xxx" references to a link to the SVN web interface by using the following (statically linked) code right after the preg_match_all for FS# references:

if (preg_match_all("/\b(SVN#|SVN )(\d+)\b/",$text,$hits,PREG_SET_ORDER)) {

 foreach ($hits as $n => $hit) { $tasks[$hit[2]] = $hit[0]; }
 foreach ($tasks as $id => $str) {
   $link = '<a href="http://dokeos.svn.sourceforge.net/viewvc/dokeos?view=rev&revision='.$id.'" title="SVN Web for commit '.$id.'">'.$str.'</a>';
   $text = preg_replace("/\b$str\b/",$link,$text);
 }

}

Although it is statically linked to the sourceforge directory of Dokeos here, it is easy to imagine what it does (use anything around 13000 as id in the link to find out) and how a configuration setting could be set to have a quick reference there.

I found this bit of code incredibly practical to get a quick idea of what changes had been made to the SVN code to fix a bug. Although it doesn't go in the same direction than anything you are talking about here, maybe someone will find it practical or try to integrate it.

Since our upgrade to 0.9.9.3, I haven't had the time to re-integrate the change (maybe someone can hint me on where to do that now, it seems it's replaced by "return preg_replace_callback("/\b(?:FS#|bug )(\d+)\b/", 'tpl_fast_tasklink', trim($text));" now, which I don't get just yet).

Attached is a patch which adds the ability to show reposittories which are secured with ssl (https urls). Additionally it adds some checks if the username and comment of a revision is empty. This could be the case in my installation and without this modification i get undefined index errors.

Don't know what drove me crazy this is the correct patch. The previous one ignored the port part of an url (e.g. https://testserver:1443/svn/test/)