I have spent more time on this over the weekend and I now have a copy of the live site on my local VM. The migration was fairly straight forward. I used trac-admin hotcopy to create an archive including the postgres database and copied that to my local VM. 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.
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. However I do not have a WikiStart page defined. So my question is what should I do? Bare in mind that I will most likely be doing something similar with the live i.a.o Bloodhound instance at some point. 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. I am no expert of administrating either Trac or Bloodhound, so any suggestions would be welcome. On 27 January 2015 at 07:59, John Chambers <[email protected]> wrote: > That would be good if you have time Ryan. I am in the process of creating > my own local Ubuntu VM with version 0.4 installed so that I can test out > the upgrade steps myself. > > Cheers > John > On 27 Jan 2015 07:52, "Ryan J Ollos" <[email protected]> wrote: > >> On Mon, Jan 26, 2015 at 3:35 PM, Branko Čibej <[email protected]> wrote: >> >> > On 26.01.2015 22:03, John Chambers wrote: >> > > As some of you may know I have recently taken an interest in the >> > > infrastructure side of the project. >> > > The following have be highlighted to me as the main priorities at the >> > > moment: >> > > >> > > 1. Ensuring the demo servers are online. >> > > 2. Re-enabling source browsing >> > > 3. Upgrading i.a.o to version 0.8 from 0.4 >> > > 4. Dealing with spam tickets. >> > > 5. Dealing with robot users. >> > > 6. Setup multi product on i.a.o. >> > > >> > > I know there will be issues migrating tickets from a single to multi >> > > product setup so I am proposing to create a new installation of >> > bloodhound >> > > at version 0.8 that will have multiple products defined. Migrating the >> > wiki >> > > content but leave the majority of the tickets in the old instance. >> Which >> > > will still be available for reference. >> > > >> > > We can then start afresh in a multi product setup. The new instance >> will >> > > have all the relevant plugins to prevent spam / robot users etc. And >> will >> > > be easier to maintain and upgrade. >> > > >> > > Let me know what you think. >> > >> > Sounds like a plan. FWIW, it really shouldn't be too hard to migrate the >> > issues from an old, non-multi-product database to the new, multi-product >> > setup, while maintaining product-specific issue numbers. >> > >> >> Yeah, it would be more ideal if we could migrate over the issues as well. >> I >> don't think we have the exact steps documented anywhere, and perhaps it's >> so trivial that the steps don't need to be documented, but I'm not >> counting >> on it. I could spend some time this weekend testing locally with a copy of >> the database. Whichever way we go with i.a.o, it would be good for us to >> understand the steps required to migrate older installations to >> multiproduct, and document if needed, so any time spent wouldn't be >> wasted. >> >> >> > We can still get the old issue URLs to work by adding some smart rewrite >> > rules to the HTTPd configuration. >> > >> > -- Brane >> > >> > >> >
