Starting with Redmine Locally - How Easy Is Migration to Server Later

Starting with Redmine locally - how easy is migration to server later?

On your scale, I'd rate it close to a 9 or 10. It's not automatic, because aspects of the configuration may have to change (e.g. where your database is located, if it's not going to be localhost on the new machine). But it's pretty close -- you'd just upload your backed-up MySQL database to the new, remote instance once you're ready to make the move, and that's about it, except for the various other configuration and installation details that you can handle at the command line. But these will vary from host to host.

The only thing to worry about is that third-party providers may have specific restrictions on what kinds of plugins or settings can be active with a given Redmine install, but I suspect that in 95% of cases there won't be any issue here either.

Is it possible to start a new redmine project with default issues?

I know you can copy existing issues, and it is even possible to copy multiple issues at once. (in the issues page, select them and right click on one of them)

Maybe the easiest way is to copy the issues from a previous project and assign them to the new project.

Anything speaking against the bitnami.org Ruby/Rails/Redmine Stack?

I've been using it for the last 6 months with 0 issues.

Recommended.

Importing Redmine to local server issue

You can modify it in the locale file: find it in config/locales/en.yml (and in other languages if you need)

you need to find the label field_assigned_to

Redmine_Backlogs fails to show successful migration in settings page

I could not answer my own question before, but now I can.
The above code was tested and works. I have been running backlogs on Windows with MS SQL successfully since.

Known issues with Redmine?

I can only suggest you look at this list of issues on the Redmine project's site - naturally, they use Redmine to track them.

We have been using Redmine for a year now (although not with git), we have about 15 users, and have not experienced any issues with it.

If you are concerned about stability, it might be an idea to use an older version with no known serious bugs, rather than the latest version.

What are the advantages of using chiliproject over redmine?

I searched StackOverflow for the "redmine vs. chiliproject" question because I am having a lot of trouble with installing plugins of any kind on the newest chiliproject version.

Usually, it looks like everything is working fine until you try to update the settings for the plugin (for example, install the Contact Form plugin and try to change something on http://SERVER:3000/settings?tab=contact_form), the debug log shows that the changes were made in the database, but they changes are never loaded back to the plugin page.

I have not been ale to find any documentation on potential changes to the plugin architecture in ChiliProject that would cause this. The plugin page does not list many plugins that are known to work with ChiliProject 3 either.

TL;DR: If you think that you will have any desire to use any existing plugins to extend the functionality of the program you choose, go with Redmine.

organization of Redmine projects?

As usual, when you configure a system you need to customise it as much as possible to try and meet your own needs. I personally don't know of any guidelines or recommendations for Redmine per-se, however I can relate what we do here and I hope that will help you! :-)

Features/Bugs/Maintenance are just ways to label your tasks so that you can filter them. These are a specific label known as a "tracker" in Redmine. You can define your own trackers for additional types of task.

Project and Sub-Project are also effectively a way of labelling your tasks, but grouping them under a broader umbrella category. When you create 'projects', you assign the trackers you will need to them. In our case, we create an API, and have distinct trackers to identify bugs, features & modifications with (effectively) duplicated tracker names so that we can identify if the tasks are for desktop or dsp programmers. The sub-projects are used to identify product lines or customisations that our customers require specific support for. We also use version labels to identify specific releases in each subproject so that we can get a nice roadmap view of all of the tasks we are tracking. We have multiple projects in our Redmine system, each configured in a similar manner, with some project tasks linked across projects as "related" issues so that we can identify dependencies.

This is just one way to configure Redmine, but is the simplest we could manage given the complex relationships between some of our projects. It is the second configuration that we have tried and we find it works well. FYI, the first configuration was on a test system to allow us to work out what we needed from the system after migrating from Trac, a couple of years ago. The current configuration has been in use for about 2 years and seems to suit our needs nicely.

As I said earlier, you need to decide what you need from the system, but the simplest approach is to think about how you view a project from the top down, configure your system to match your processes, and not change your processes to match the tool - always the more 'disastrous' option IMHO. I wouldn't recommend tracking bugs and features etc in separate projects, as getting your roadmaps together is usually harder, and it also makes it harder to visualise the total task load for a given project. Even dividing task types into subprojects could be problematic, as it complicates things if you find you need to support multiple product release cycles, adding to your workload in terms of managing your Redmine system.

That's about all I can think of for now. I hope that helps you. :-)

How do I manipulate a VARCHAR field in SQL to simplify a collection of roadmaps in a Bugzilla to Redmine migration?

This query gets you all the 3-character version names of all existing versions, by project:

SELECT DISTINCT v.project_id, Left(v.name, 3) newversionname
    FROM issues i
        INNER JOIN versions v ON i.fixed_version_id=v.id

You'll need a list of all 3-character version names which do not yet exist:

SELECT f.project_id, f.newversionname
    FROM (
        SELECT DISTINCT v.project_id, Left(v.name, 3) newversionname
            FROM issues i INNER JOIN versions v ON i.fixed_version_id=v.id
    ) f
    LEFT OUTER JOIN versions v2 ON f.project_id = v2.project_id and f.newversionname=v2.name
    WHERE v2.project_id is null

You'll need to insert new version for each result of the above query (I'll leave the adaptation of the above query as an INSERT query to you...).

---

EDIT: Updated query to add version details

SELECT f.project_id, f.newversionname, v3.description, v3.created_on, v3.updated_on
    FROM (
        SELECT v.project_id, Left(v.name, 3) newversionname, MIN(v.id) minversionid
            FROM issues i INNER JOIN versions v ON i.fixed_version_id=v.id
            GROUP BY v.project_id
    ) f
    LEFT OUTER JOIN versions v2 ON f.project_id = v2.project_id and f.newversionname=v2.name
    INNER JOIN versions v3 ON f.minversionid=v3.id
    WHERE v2.project_id is null

This will simply select the details of the version with the lowest id for each new version.

---

Note: This will break if you have version bigger than 9 (ie 11.234 becomes 11.).

Now we now that for every issue associatted with an old version, there exists a new 3-character version. The following query shows which one:

SELECT DISTINCT i.id, v.id oldversionid, v.name oldversionname, v2.id newversionid, v2.name newversionname
    FROM issues i
        INNER JOIN versions v ON i.fixed_version_id=v.id
        INNER JOIN versions v2 ON LEFT(v.name, 3) = v2.name and v.project_id = v2.project_id
    WHERE v.id <> v2.id

You may use this query and adapt it as an UPDATE query after a sanity check. You'll still need to add the criteria to distinguish between the open and closed issues (status_id).

Hope this helps with your migration, have fun with redmine!

---

Related Topics