Redmine

+1
Good idea.
Also it can be a simple way to make backup.

I agree this would be great, and just what we need for a number of cases.

This relates to http://www.redmine.org/boards/2/topics/5754#message-5761, where just this functionality is required.

I would love to help out if I can. I am not a coder. My skill set is more geared to project management and testing/debugging. Let me know if I can assist.

+1

Recently I received a request to Import only a specific project from our test server to PROD. (MySQL Server)

I did it manually exported records from table by table & imported them in PROD. Took few hours for about 100 Issues.

It will be nice to have this feature to export a single or multiple project data from one server & import to another RedMine server.

+1

Yes, it would be very nice to export/import projects and administration/user settings. Good for backup, moving between servers :)

+1

+1

We have 3 redmine server... And now i try to merge it into one server...
Server 1: 14 project [100+ issues]
Server 2: 3 project [100+ issues]
Server 3: 8 project [100+ issues]

Pls make a migration tool...

/* mysql_dump is not a good way: 'issueId = (1..100+) is in all server */

thx

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Raito Yitsushi wrote:

+1

We have 3 redmine server... And now i try to merge it into one server...
Server 1: 14 project [100+ issues]
Server 2: 3 project [100+ issues]
Server 3: 8 project [100+ issues]

Pls make a migration tool...

/* mysql_dump is not a good way: 'issueId = (1..100+) is in all server */

thx

dfdf

+1

+1

+1
The real problem relates to the issues IDs (and in particular the fact that these IDs can be used in SVN commit messages to reference the issue). If Redmine had project-specific issue IDs (for example: shortName-1234), it would be simple to import a project.
With global server IDs, I fear that the correct import of a project will not be possible (because that will change the IDs, so at least the references on SVN commits will be lost or wrong).
However, it's a real problem !

Thomas Zlika wrote:

+1
The real problem relates to the issues IDs (and in particular the fact that these IDs can be used in SVN commit messages to reference the issue). If Redmine had project-specific issue IDs (for example: shortName-1234), it would be simple to import a project.
With global server IDs, I fear that the correct import of a project will not be possible (because that will change the IDs, so at least the references on SVN commits will be lost or wrong).
However, it's a real problem !

mmm....

1. If you have two different SVN repositories you must first of all merge them, maintaining all the history and creating a report with OldCommitReference->NewCommitReference. This is not a easy task, in any case it is related only to SVN. With such a report you have to update the RedMine servers renaming oldReference with newReference wherever it was used (wiki, notes, etc).

2. Once you merge two RedMine Servers you need a report with OldIssueID->NewIssueId. With that report you have to update all the Commit Comments in your SVN repository, replacing old issue id with new issue id as described in the Subversion FAQ (the Import process could do that automatically). You need to replace the issue IDs not only in SVN but also in all the notes, wiki of RedMine.

Sure, with a global issue ID (like with GIT commits) it would be easier to merge two servers, but the simple incremental Issue ID number is more human friendly....

+1 This would be useful, as I often projects that have started off in my own Redmine later require more access and need a Redmine of their own.

It's nearly impossible to have a clean answer to this question. Something could be built on top of yaml_db gem (https://github.com/ludicast/yaml_db ; it generates a database-independent export in YAML). But the latest posts are right on issue IDs, and I can't imagine such a change in a near future sorry.

Dear Jean-Baptiste,

thank you for taking the time to comment.

Okay, it is technically hard (nearly impossible) to provide this feature, so we'll have to leave without it (unless somebody volunteers to pay [a lot] for the development work).

Suppose several projects grow on one Redmine instance, and one of them needs to be transferred to a new server. Could one clone the whole system, and then on the cloned system delete all projects apart from the desired one? This is not pretty, but at least a workable solution available now.
Would we expect this to work?

Thank you,

Hans

Hans: indeed ! It can be a solution if your projects/users are strongly separated from each other. It could even be partially scripted.

1. you might be able to solve it outside of Redmine, with a caching reverse-proxy, multiple passenger/mongrel instances (or even a different hosting solution), etc.
2. you can report any specific problem here, I think we would be happy to help Redmine be better with high traffic loads

A couple things:

I also saw some code for a tentative way to do this over here: http://www.redmine.org/boards/1/topics/8077

Also, the unique id thing is the main problem definitely. I think there are a couple ways to possibly handle this:

1) start down the path of UUID's for objects. This would also have the benefit of allowing people to choose between a system wide unique issue number or a project wide unique issue number. This could possibly be done with the help of a plugin, but would more likely be best implemented at the core of redmine. See http://en.wikipedia.org/wiki/Universally_unique_identifier for some background. Drupal is a project I know that has some implementations of this http://drupal.org/project/uuid but almost all programming languages have at least one library for using them (ruby has 3-4 i think)

2) use a plugin to manage the mapping of old id's to new id's and then supersede the use of the old id's when linking between version control, issues, wikis, etc.
For example you import issue #253 from site1.com and it becomes #12 on site2.com... when rendering the a link to issue #253 on site2.com, based on per-project settings, it knows to link to issue #12 instead. (The plugin would probably have to create a custom field on the relevant object to store the old id's)
This method could work relatively easily but would probably be a bit hacky. There might need to be a way to resolve/choose which reference you're talking about at times.

+1

+1

Could you please provide me updates about this feature?
I want to transfer redmine data from one machine to another machine.Is there any solution to perform this?

+1

Just built a new server for production and would like to import a project from my old test server. Over 100 issues

+1

(it seems there is no easy way to switch from sqlite3 to mysql, so a data import/export feature could take care of that.)

+1

I need merge several redmine servers (with different databases) in one

Marcelo Soares Souza wrote:

I need merge several redmine servers (with different databases) in one

I haven't thought of that, but now that you mention it:
Being able to import/export single projects would mean way better data portability, thus also more peace of mind hosting-wise. You could start of a little redmine on your dev box with sqlite3 knowing that if demand gets out of hand you can switch to a 'managed' hosted (like plan.io).
It is already the case with wordpress(.org/.com) and their implementation works really well.

+1

+1

Can't it be done in this way:

All issue IDs will be extended internally by the according project ID. The projectID can be written in links, but is not needed in all cases.
The syntax for issue links (e.g. in wiki) will be extended by someting like #projectID:issueID
and alternatively with previous syntax #issueID referencing to local project (if #issueID occurs) else to other project (if #issueID occurs there). This means that the issueID will be specific only for 1 project in future (not for complete redmine).

So when a project is imported to a different redmine installation all issues will keep their numbers and will stay linked to the actually imported project. Just links to different projects need to be broken, if the according project is not imported in the same time.

Attachments need to be stored in a own folder per project.
Users will be created as new users, or (if name is same in old and new redmine) will be mapped accordingly.
All needed trackers will be transfered as well as workflows, news, wiki and forums.

Also if not all information is transferred it will be better than nothing.
This feature is really needed, if you use redmine for many projects (and therefore on some installations).

I don't like the idea of non-unique issue ID's.

We have two instances of Redmine currently, and are looking to merge these. Already staff use the issue ID to point people to the relevant issue, and with two instances this can be very confusing. If the issue ID was only relevant when mentioned in the context of the project there would be chaos! Different business units use different projects, with their work going into subprojects of that B.U. Project space. There is enough cross-functional/cross project team work going on that noone would know what issue 123 meant anymore (we are lazy enough to leave off the project identifier).

Holger Kluge wrote:

Hi,

i also thought about this and stumbled about http://www.rubyrep.org. They have a >screencast for bidirectionally synchronizing two redmine instances at >http://www.rubyrep.org/screencast.html.

I did not test this myself, but it may be worth a try...

Why don't they sync the two tables 'schema_migrations' and plugin_shema_info'?

Does that mean i can have different plugins setups in both redmine instances?
If redmine standard tables are never touched by plugin migration, can this work?