On 12. Jul, 2013, at 2:29, Antonia Horincar wrote: > On Thu, Jul 11, 2013 at 10:36 AM, Matevž Bradač <[email protected]> wrote: > >> >> On 10. Jul, 2013, at 1:45, Antonia Horincar wrote: >> >>> Hi devs, >>> >>> In an earlier thread, Joe told me that a reasonable order of priority for >>> implementing the embedding feature would be: >>> Ticket > Milestone > Version > Product > Component > Source > Everything >>> else >>> >>> I managed to implement the back-end part which deals with embedding >>> tickets, milestones and products (there are some details that I still >> need >>> to work on, though), but I have some questions regarding versions, >>> components and sources. (By the way, I have committed the code I wrote up >>> to now to the bep_0007_embeddable_objects branch, some feedback would be >>> more than welcome). >>> >>> What does version refer to? Does it cover an entire product? And how can >> I >>> add or change a version? >> >> A version is basically a tag which is used to identify which version >> of the product a specific defect relates to (e.g. #543 is bound to >> version 0.5.3). You can change a ticket's version through the ticket >> form, and you can add/change product's versions through the admin >> page - there you select a specific product in the dropdown and then >> click on "Versions" in the menu. >> >>> Also, can different versions of an object be accessed separately through >>> the application? Because I'm not sure how would a user be able to choose >> to >>> embed a specific version. Or a specific component, for that matter. >> >> Versions are mainly used for reporting purposes. If you look at the >> specific product's dashboard (e.g. /main/products/@/dashboard) you will >> find a widget which displays all versions for that product as well as >> a number identifying how many tickets are bound to each version. >> If you then click on a specific version you will get a full report >> with all the ticket details. Perhaps this report is what could be the >> embedded version in question? > > > I'm not sure that I got it right. The things embedded would be the saved > queries (the reports)?
Sorry, I meant to say "link to this report", not the report itself. (Similar to what is currently displayed on the dashboard) > > >> >>> >>> Also, what would an embeddable source look like? What source information >>> should be embedded? I am not sure how the source feature works in >>> Bloodhound right now, because I didn't quite understand how the >> repository >>> administration is done. >> >> The source browser currently only works with local svn repositories, that's >> why it's not yet enabled in the Bloodhound tracker. You can however see >> the trac's browser at http://trac.edgewall.org/browser. >> Note that in Bloodhound the source repositories are not bound strictly to >> specific products. Instead, the repositories are created globally and then >> linked to each specific product as needed. In this manner a single >> repository >> can be shared through multiple products. >> >> If you wish to install and configure the source browser locally: >> - Installation of subversion server, and a local repository needs to be >> created. >> - Python with subversion bindings. On OS X this means installing a new >> python >> from macports/brew, as the default installation doesn't contain the >> package. >> The new version then must be used to create the BH environment. >> - Subversion needs to be enabled in environment's base.ini, under >> [components]: >> tracopt.versioncontrol.svn.* = enabled >> - The repository then needs to be added to BH through >> /main/admin/versioncontrol/repository >> - Repository needs to be synced with BH: >> - stop the server >> - run 'trac-admin <path_to_environment> repository resync >> bloodhound' >> - start the server >> Once the above is complete you can link repositories to product through the >> product admin pages (e.g. >> /main/products/@/admin/versioncontrol/repository). >> >> > Thank you for the guidance. I have installed a subversion server today, and > set up a repository. I encountered some problems when installing the > subversion bindings, but hopefully I'll manage to fix them soon and then > I'll be able to sync the repo with Bloodhound. I'm not sure what source > details should be embedded, though. Besides the actual code. The code or even file paths may contain too much information to be usable in an embedded manner. You could display all the revisions in which the specific ticket was changed, linking them to the repository browser. When a user clicks that link, the changeset page is shown with all the detailed information on what was changed (e.g. diffs, paths etc.). This is currently already visible on the ticket page, but since we don't have a local repository running, the links are not working. For a working example, you can refer to Trac's tickets, e.g. http://trac.edgewall.org/ticket/1102 contains links to http://trac.edgewall.org/changeset/1178 and http://trac.edgewall.org/changeset/1497 > > > >> -- >> matevz >> >> >>> >>> Thanks, >>> Antonia >> >> > Antonia
