bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Chambers <cham...@apache.org>
Subject Re: Dogfooding multi product on i.a.o/bloodhound
Date Mon, 16 Feb 2015 14:33:14 GMT
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 <chambej@apache.org> 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" <rjollos@apache.org> wrote:
>
>> On Mon, Jan 26, 2015 at 3:35 PM, Branko ─îibej <brane@wandisco.com> 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
>> >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message