| ../irclogs/#mantishelp.2009-11-10.log | ||
| --- scribe started --- | 00:00 | |
| dirtyal | hello | 12:41 |
|---|---|---|
| dirtyal | I've detedcted a problem the code integration | 12:41 |
| dirtyal | when we close a ticket via SVN | 12:41 |
| dirtyal | the fixed_in_versionin not set | 12:42 |
| dirtyal | looking in the code | 12:42 |
| dirtyal | the funcition bug_resolve | 12:42 |
| dirtyal | in called passing $t_version in blank | 12:42 |
| dirtyal | in Source.API.php | 12:42 |
| dirtyal | any ideas? | 12:42 |
| dhx_m | did you setup branches correctly? | 12:47 |
| dirtyal | No, I did not set up branches, could tou give a hint how to do it? | 12:48 |
| dhx_m | maybe it only works with git repositories, I'll check | 12:51 |
| dirtyal | It closes the tocket and updates it ok | 12:51 |
| dirtyal | just the fixed_in_version problem. I could just make the update in the data in the code. | 12:52 |
| dirtyal | but if it is a bug, it would be better to get it fixed right. | 12:52 |
| dhx_m | hmmm not too sure how it's done, I've never tried | 12:53 |
| dhx_m | nuclear_eclipse might be able to give you a better answer :) | 12:53 |
| dirtyal | it gets the verson form the mappings $t_version = $t_mapping->apply( $t_bug_id ); | 12:54 |
| dhx_m | firstly | 13:04 |
| dhx_m | make sure you enable "Branch Mappings" in the plugin configuration of the SourceIntegration plugin | 13:05 |
| dirtyal | is it enabled because it enters this part of the code if ( $t_enable_mapping ) { | 13:05 |
| dhx_m | then go to Repositories => Manage in the main menu to see configuration options for each repository | 13:05 |
| dhx_m | you can then set a branch, strategy, version and regular expression | 13:06 |
| dhx_m | to define how the plugin automatically finds the version to set fixed_in_version to | 13:06 |
| dhx_m | works for WebSVN and Gitweb (only two I've tried) | 13:06 |
| dirtyal | strange it that it finds everything, the only thing it should to woudl be get the taget_verion an dapply to fixed_in_verion or not? | 13:07 |
| dhx_m | yeah that does sound like a usual option to me | 13:09 |
| nuclear_eclipse | dirtyal: you need to set up branch mappings | 13:09 |
| dirtyal | would tou give a exemple of this? | 13:09 |
| dhx_m | s/usual/useful | 13:10 |
| nuclear_eclipse | well, on our tracker at mantisbt.org, mastre branch maps to version 1.3.X, and master-1.2.x branch maps to version 1.2.X | 13:10 |
| dhx_m | do you see: | 13:10 |
| dhx_m | Branch Mappings | 13:10 |
| dhx_m | Branch Strategy Version ? Regular Expression ? Delete | 13:10 |
| nuclear_eclipse | dirtyal: it's mainly an issue of "not assuming anything" | 13:10 |
| nuclear_eclipse | or rather, only assuming exactly what the user tells it to assume | 13:11 |
| dirtyal | I thought that it would just set the fixed_in_version with the target_veriosn when a ticket is resolved/closed | 13:11 |
| dirtyal | I have 39 repos, each time I branch I must update the mappings? | 13:12 |
| nuclear_eclipse | dirtyal: I never really even considered that an option -- in many cases where I work, fixes do not always make it into the target version | 13:12 |
| nuclear_eclipse | however, I can look into making that an option | 13:13 |
| dirtyal | ok, but than ou would change the target version of the ticket, or not? | 13:13 |
| nuclear_eclipse | depends on the situation | 13:13 |
| nuclear_eclipse | sometimes the fix would get committed to a different branch before it's known if the fix will be ported to the original target or not | 13:13 |
| dirtyal | I see, you have a more complicated, but more powerfull way of doing | 13:14 |
| dirtyal | the integration | 13:14 |
| dhx_m | I can see why it may be useful in some environments (with no branching) to copy the target version to the fixed in version upon a resolving commit being made | 13:15 |
| dirtyal | We have branchs | 13:15 |
| dirtyal | but the branch has a versoin | 13:15 |
| dirtyal | and tickets assigned to that version | 13:15 |
| dhx_m | but it'd be a very borderline case | 13:15 |
| dhx_m | actually, I don't really see the point | 13:15 |
| dhx_m | yes so set each branch to have a different version? | 13:16 |
| dhx_m | or do you have multiple branches per Mantis project? | 13:16 |
| nuclear_eclipse | dhx_m: I think his point is just that it would be a lot of work to maintain all those mappings for his 39 repos... | 13:16 |
| dhx_m | multiple concurrent versions per Mantis project I mean? | 13:16 |
| dirtyal | I tought, till now, that only the ticket number would matter | 13:16 |
| dhx_m | yep | 13:16 |
| dirtyal | I am one project, this project has 39 repositories | 13:17 |
| nuclear_eclipse | dirtyal: wow, what project? :) | 13:17 |
| dirtyal | yep, it is complex. | 13:17 |
| dirtyal | so the branch is the actual version running and th trunk is the next new version that will come out | 13:18 |
| dirtyal | and tags hold the history of course | 13:18 |
| dhx_m | what happens in your proposed workflow when someone hasn't set the target version? | 13:18 |
| dhx_m | does SourceIntegratation just ignore the need to update the fixed_in_version field? | 13:19 |
| dirtyal | We always set a target version for eevery ticket | 13:19 |
| dirtyal | in mantis | 13:19 |
| dirtyal | yes, source integration | 13:20 |
| dirtyal | does not ginf any mappong and does not set fixed_in_version | 13:20 |
| dirtyal | dhx_m and nuclear_eclipse i have to go to the doctor to do a exam, I have a appointment, I will be back in a hour to continue the talk woth you guys if its ok? | 13:22 |
| nuclear_eclipse | sure thing | 13:22 |
| nuclear_eclipse | I'll be here :) | 13:22 |
| dirtyal | tks | 13:22 |
| dhx_m | I'll be gone, but you can leave messages here | 13:22 |
| dirtyal | tks be back soon | 13:22 |
| dirtyal | just got back | 14:43 |
| dirtyal | when you say mapping branchs | 15:09 |
| dirtyal | I have to force a new branch to close in a determined version and each branch must be reconfigured? | 15:10 |
| nuclear_eclipse | dirtyal: more or less | 15:12 |
| nuclear_eclipse | I'm pondering what you're looking for though | 15:12 |
| nuclear_eclipse | perhaps I can find a way to meet both needs | 15:13 |
| dirtyal | that the way we work, the projet is opmon, the veriosn out is 4.0.4, there is brancj for it | 15:24 |
| dirtyal | the verion in development is 4.1, the trunk | 15:24 |
| dirtyal | so we have tickets on both verions and even on verions in the future | 15:25 |
| nuclear_eclipse | right, that's similar to how it works on mantisbt.org | 15:25 |
| dirtyal | so the tickets on on versoin 4.0.4, target_version, when closed should get fixed_in_version 4.0.4, if they are no fixed there due to anu probklem, their target_versin in changed and so on | 15:26 |
| nuclear_eclipse | however, on mantisbt.org, I have master branch (like trunk) mapped to 1.3.X version, and master-1.2.x branch (forked from master when RC1 was released) mapped to version 1.2.X | 15:26 |
| nuclear_eclipse | and it determines the fixed-in versoin just based on what branch the fix is committed to | 15:27 |
| dirtyal | ok, when you fix a bug on a 1.2.x branch, how to do tag the fixed_in_verion? | 15:27 |
| dirtyal | I see now | 15:27 |
| dirtyal | this would no work for me because of the many repositories the project has | 15:28 |
| dirtyal | and the way we organized | 15:28 |
| dirtyal | I think | 15:28 |
| nuclear_eclipse | basically, it doesn't make an assumption of what the fixed-in version should be; there's an explicit mapping of VCS branch to fixed-in version | 15:28 |
| dirtyal | I see | 15:28 |
| nuclear_eclipse | dirtyal: I think I know a way to implement a method that you would want | 15:29 |
| dirtyal | maybe, it could be that if there is no mapping | 15:30 |
| dirtyal | the target_version it set in the fixed_in_version | 15:30 |
| nuclear_eclipse | I'm thinking more along the lines of a) adding a way of adding a mapping for "all other branches" such as "*", and then adding a new strategy of "same as target version", in which case you would only need to set a single mapping for each repository with that strategy | 15:31 |
| nuclear_eclipse | I still want the choice to be explicit | 15:31 |
| dirtyal | that is also very nice | 15:32 |
| dirtyal | it keeps all the possibilities open | 15:32 |
| dirtyal | does't break anything | 15:32 |
| nuclear_eclipse | and what I'm thinking is that "*" would be lowest-priority, so you could still have explicit mappings that take precedence over it | 15:33 |
| dirtyal | perfect | 15:33 |
| paulr_ | dhx_m / nuclear_eclipse moo? | 19:11 |
| nuclear_eclipse | howdy paulr_ | 19:11 |
| paulr_ | lang api? :P | 19:11 |
| paulr_ | oh | 19:12 |
| paulr_ | hi | 19:12 |
| paulr_ | ;) | 19:12 |
| * paulr_ warns his had a crap day at work | 19:12 | |
| CIA-9 | Mantisbt: robert.munteanu * rf7435b8ce5c5 /api/soap/mc_issue_api.php: Issue #11138: Error when retrieving bug via SOAP | 20:09 |
| CIA-9 | Mantisbt: robert.munteanu master-1.2.x * r2656c2f57698 /api/soap/mc_issue_api.php: Issue #11138: Error when retrieving bug via SOAP | 20:10 |
| CIA-9 | Mantisbt: jreese * r9f2e24daf90d /core/string_api.php: Commit 55878bd7 escapes using the wrong delimiter | 20:51 |
| CIA-9 | Mantisbt: jreese master-1.2.x * re9d7b203b054 /core/string_api.php: Commit 55878bd7 escapes using the wrong delimiter | 20:51 |
Generated by irclog2html.py