Brane, I do like this idea. The way I would see it setup would be that the only things in the global environment / base url would be the bloodhound / trac wiki pages and potentially only tickets about the infrastructure of this instance of bloodhound (though these could be in a new product as well).
We could then have a BH_ISSUES product which would contain all the old tickets and attachments. But like I said previously I am not an expert in Trac/Bloodhound or Apache HTTP. So any help or pointers to documentation would be very gratefully received. Cheers John On 16 February 2015 at 16:37, Branko Čibej <[email protected]> wrote: > On 16.02.2015 16:25, Olemis Lang wrote: > > Hi John ! > > :) > > > > On 2/16/15, John Chambers <[email protected]> wrote: > >> I have spent more time on this over the weekend and I now have a copy of > >> the live site on my local VM. > > [...] > > > > \o/ > > > >> I already had bloodhound v0.8 > >> installed so it was just a case of replacing the > >> bloodhound/environments/main with the archived one and restoring the > >> database. I had to make changes to the base and trac ini files because > of > >> path changes and I then had to do a trac-admin upgrade to get the > database > >> to the required version. > >> > > Database upgrade should not be quite problematic considering that > > multi-product plugin's columns have not changed since some time and > > 4.0 includes MP DB structure but not the other aspects , mainly the > > isolated product envionments developed for BH>=0.6 . Something worth > > considering is the state of other plugins e.g. relations . Is it > > enabled and working ? > > > >> Now the main problem I have is that the process has created a new @ > >> prefixed default product under which all the old tickets and wiki pages > can > >> be found. > > Would you mind if default product prefix is set to something different > > , let's say BH ? > > > >> However I do not have a WikiStart page defined. > > I guess you mean in the global environment i.e. at base URL . > > > >> So my question is > >> what should I do? > > It is possible to create the wiki page and that's it but ... > > > >> Bare in mind that I will most likely be doing something > >> similar with the live i.a.o Bloodhound instance at some point. > >> > > ... the question is what's going to happen with all the URLs (e.g. in > > messages instructions , archive , ...) pointing at i.a.o/bh/... now > > available at i.a.o/products/PREFIX/... (PREFIX=@ or PREFIX=BH or ...) > > > >> The options I can think of are: > >> > >> 1. Change the setup so that we are using the default product to serve > all > >> the pages. > >> 2. Create a new StartWiki page to allow the users to select the product > >> they want to work with. > >> > > Considering the answers to questions above I might have another > > proposal ... which is basically to continue hosting the default > > product at i.a.o/bh other potential new products at > > i.a.o/bh/products/PREFIX and global admin at some other > > non-conflicting URL e.g. i.a.o/bh/global (<= but may a different > > naming convention be chosen as well) > > > I'd really hate having BH tickets etc. in the default product. They > should be in the BH/bloodhound product. To maintain URL compatibility, > we can design rewrite rules for the Apache config that make all > product-scoped tickets, pages, etc. visible at their old locations. > > The reason why it makes sense to scope all BH stuff into its own product > is that it will then be easier for other projects to adopt BH as their > issue tracker. Most ASF projects currently use Jira, but some use > Bugzilla and at least one uses the tracker at tigris.org. If we make > transition to Bloodhound moderately easy, they may switch (and we may > convince Infra to provide a more powerful VM for the BH host). > > -- Brane > >
