So we have this project which uses Mantis as bug tracker tool and in the company the corporate bug tracking tool is Bugzilla. This means we will have to use Bugzilla soon.
I searched for tools that can be used to migrate from Mantis to Bugzilla and I only found this m2bz tool which seems to work for Mantis 0.17.5 and Bugzilla 2.16.3 but seems also kind of dead since 2003...
Do you guys have already try to do such a migration? The Mantis version used is 1.1.8 and the Bugzilla one is 3.0.1.
Thanks in advance!
You can load data with importxml.cgi, which implies that you only need to dump your existing database into the proper XML for the migration.
We usually migrate other Bugzilla installations into our big Bugzilla database with a script that copies the data from one db to another, mapping bug ids, users, etc. I tried to do much the same thing when I had to migrate JIRA stuff. It turned out to be a major PITA!
I would have been much, much better off working on how to dump JIRA in the correct XML.
The data model changed a lot between 2.16 and 3.X, so whatever m2bz tool you found probably won't do what you want.
Do you know the datbase structure for Mantis?
Because you can import sql scripts in the BugZilla database, to make the migration yourself.
The Bugzilla database is:
http://www.faqs.org/docs/bugzilla/dbschema.html
I couldn't find it for Mantis though :-(
Related
I want to use Pentaho for my work. After a bit of research I found that to store the ktr/kjb files I can have either database as a repository or I can use file system as a repository. However I don't find any benefits of using database as a repository over file system. The basic purpose of repository here is to create a common location where I can keep all the developed ktr/kjb files in production environment. Basically if I consider the database repository, it will hold all the developed ktr/kjb files in production and every time I need to run a job/transformation I will connect to database to get the respective ktr/kjb file (similar to how informatica stores transformation) on the other hand file based repository will be like a folder holding all the developed files.
Can somebody here will be able to explain pros and cons of both type of repository?
Please let me know if you need any other information.
Thanks in advance.
When several people develop on the same jobs/transformations, the database repository will hold the changes, and ensure the latest versions.
The pros of a filesystem is of course ease of backup, no database connection that can trouble you, and the possibility to use other, more modern and mature version control systems for the files, than the database repositories use.
If you are using the free community edition, I would definitely go with the file repository, along with external file-based version control and migration systems. If you are using the enterprise edition, then you might want to consider the database repository, since you can then use Pentaho's built-in version control and migration systems.
I feel like I'm experiencing a common problem, but I wasn't able to find anyone asking about it.
As the title indicates, we're forced to use AccuRev for SCM. We have our development stream under our QA stream. Let's say we're working on a big project that will be in QA for weeks before being released (we're following a scrum strategy). In the meantime, there's a bug fix that needs to go out before this big project. The problem is the bug fix affects some of the same files the big project uses. How would I get my files from development to production, without bringing the big project with me?
Sorry, I hope that makes sense!
Thanks!
If you are using the change package feature in AccuRev, you can select that issue and just promote those changes into the production stream.
Otherwise, you will need to determine the promote transaction(s) of the of the bug you fixed in development and change palette those fixes into production.
I think I found a solution that will work for us.
I plan on creating a snapshot off of the development stream after each successful deployment to production. Bug fixes/smaller projects will work off of this snapshot. That way I can keep anything I'm currently working on in DEV from getting inherited into my bug fix. When I'm ready to deploy my bug fix, I'll create another snapshot and re-parent my big project there. Then I'll revert the change package in QA and development, re-parent my bug fix to development, and promote as normal.
It's a slightly modified version of what's explained in this article: https://accurev.wordpress.com/2008/03/27/pattern-for-stable-development/
I'm newbie in OpenErp and i'm just using basic functionnalities of OpenErp6 and i want to upgrade to OpenErp7.
I'm using it under Ubuntu11..Is there a tool to upgrade it to The 7 version ?because i searched in google and i found that i must uninstall it manually and reinstall the latest version .
Thank you
If you want to keep your data, you have two ways of doing this:
get support from the OpenERP editor: they sell a migration solution, for a not very high price.
get in touch with and contribute to the openupgrade project which tries to build an opensource migration solution. The migration to 7.0 is not yet ready as of today, so you'll need either wait or contribute to get it good enough to migrate your instance.
On the other hand, if you have very little data as you mention in your comment, you can probably migrate by hand be creating a fresh OpenERP 7 instance, and manually recreating your entries in that instance. Obviously, this is not scalable.
can anyone give an detailed procedure on how to
migrate projects from gforge version(4.5) to teamforge version 5.2.0.
Migration includes source repository, bug tracking, wiki and discussions.
is it possible to shift all of them.
What's the best way to handle a situation like this?
Thank
You
Teamforge uses Subversion, so assuming you have commandline access to the server then you can use the svnadmin dump and svnadmin load commands.
You will need to run these commands for each repository.
Some (I don't know which) of the pages and wiki are also stored in subversion repositories, so you may be able to migrate that using the same method.
I am to migrate a Websphere machine (including the applications which run on it) to a new machine. They wanted a clean install of the OS and WebSphere, so I did that. I also took a full file backup of all of the applications they had on the old server. The problem is that to re-install them on the new server, the WebSphere dialog asks me for the JAR/EAR/WAR file, which I don't have.
Is there any reasonably easy way to simply extract the backup of the WebSphere application files I have taken from the old maching, and simply configure the new machine to use them? WAR, etc. is a nice feature to have, but to be forced to use it seems silly.
Edit: The existing WebSphere server is still up and running in production.
Edit: The old server is WAS 3.5, which means it doesn't even have an export function, sadly. Also, the directory where it actually runs the content from has a completely different structure (consisting of like a a %/Web and %/Servlet, where % is the context path of the application). In the "Install" section, it doesn't even mention EAR or WAR, only JAR. I am currently thinking that perhaps the best thing to do might be to just copy the directory over to another WAS 3.5 system and then upgrade that system (and hope it converts the folder structure and updated the config as part of the upgrade).
Edit: The closest thing I have found to a solution so far is this link:
http://www.javazoom.net/services/newsletter/was4.html (though I am not sure if that tool is available or relevant for WAS 7.x).
This has to be a problem other people have run into before, but I can't find a solution anywhere on the WEB.
Thank you!
Here do they have sample Jacl scripts one can use to export/import appserver's configuration. So that is what you can start with. If your new bow uses the same version of WAS (and the same topology if it is not a standalone box) as the old one, it might be a (relatively) safe process.
Migration between different versions of Websphere might be somewhat more tricky, but I'm sure IBM published at least one redbook on that topic.
If you still have the old server running, than just export the apps and you have the war/ear files. However, If you don't know the configuration for the apps, you are screwed. However, I am sure IBM has tools that you can use. Some of the paid tools look even nice and user friendly (at least according to their sales demos). I can't tell you what you need, since I don't know what documentation you have for your apps. But as it looks like there is not much there, otherwise you would just install the application the same way they were installed on your old server and use the binaries (war, ear, jar) that are archived somewhere.