How do lipforge and cbp-forge compare? What can be migrated?

 // accueil created: 2012-06-18 - last changed: 2012-08-14


CBP-Forge (Redmine) features vs Lipforge (old Gforge) ones

This comparison is given without any particular order. For each feature used in Lipforge, we give a short description of it's status or the equivalent feature in Redmine and state whether we take care of the corresponding data migration or not. We will not dwell on the sophisiticated project management features of Redmine (Versions, Gantt…), since, as can be seen from our experience on Lipforge, they are almost never used for the kind of projects hosted on a local forge.

Source depot

Redmine has no support for CVS but that was the only supported system in Lipforge (apart from a handfull of manually installed SVN projects). But Redmine can work with (has plugins for) SVN and Git, which have distinctive advantages over CVS (see here, from CVS to SVN and there, from CVS to Git). No, no, no, we will not to fire up the version control systems war again!

Post-commit notifications can be sent to the developers of a SVN project (Git is under investigation). But there is no support for mailing lists (see below).

Repositories will be migrated from CVS to SNV or Git.

Mailing lists

Redmine has no integrated mailing lists system. This feature was very seldom used on Lipforge. We anticipate this wil not be an issue for our users. There are many alternatives at hand, even if they lack the not-so-close integration one could find on Lipforge. No migration of the handfull of existing ones is planned.

Trackers, forums...

Redmine and Gforge have similar concepts, should this kind of feature needed. But the data structures do not fit together. These features were seldom used anyway. No data migration will be attempted.

Documents

Redmine has the notion of documents too, but it is more complex. As a mater of fact, a Redmine document has more to do with a directory than to an individual file. When a new “Document“ is created, a new container is opened. The name and the description are attached to this container. If we use the neutral term of “container”, it is because you can not create a container inside another container, which differs from a traditionnal file system behavior for directories. Lipforge had the notion of “information groups“ with immutable, system defined tags wereas Redmine allows for users to define their own containers tags. On the other hand, individual files metadata are restricted to a description in Redmine and only when added from the web interface. By default there are only two document categories: “User documentation” and “Technical documentation” more can be created, on system-wide basis only, and only by the administrators.

Individual documents can be added to (or withdrawn from) the container via the web interface.

The container and the files can be accessed through their own URL (in a read-only mode). URLs are logically disconnected, what can be a bit misleading as containment is not obvious from the URLs.

The container can also be accessed through the WebDav interface (in a read-write mode) under the document/title_of_the_document directory. Files can be added/deleted to/from the directory. A new container can also be created (with default metadata), but again no container inside a container.

Documents and their metadata (well, with a description, at least, for a bunch of them) will be migrated between systems.

Files

In Redmine, they are stored in a directory that can be accessed via the WebDab protocol. This allows for in-place editing of documents as long the editor understands WebDav. This is the case of most modern office suites (MS Office, {Open|Libre}Office).

But Redmine has not the sophisticated notion of “release” Gforge has. This feature can be mimicked, less rather than more, through “Documents”, whithout metadata (release notes...) or through the Wiki. The presentation consistency heavily depends on the user's stern dedication.

Files will be migrated between systems. If needed, this can be an occasion to refactor data organization. We will check this with project managers in migration time.

Web site

Redmine has a different notion of a project Web site than Gforge. In the former case it is a Wiki, in the Textile syntax, in it's RedCloth incarnation. In the latter, it was a bunch of HTML pages directly encoded by the project members. There is a huge syntactic gap between HTML and Textile. There are tools that allow for some kind of “conversion” by pouring raw HTML into the Wiki pages. Nevertheless, manual data massaging and pages linking is required for any mildly sophisticated site. Support will be provided for migration, but extensive user input may be necessary.

Private/public project

Redmine natively correctly supports private project where we had to hack Gforge to make privacy acceptably tight. It adds an extra flexibility with the concept of subproject: for instance, the parent project may be private whereas the child one may be public.

User accounts

On Lipforge, all users (Éns “insiders” and “outsiders” as well) had to create specific accounts. On the other hand, the CBP-Forge is plugged into the Éns identification/authentication system. It means that “insiders” will not have to created an account since they will use the same account for the forge operation that for other Éns services (mail, lab workstation login, etc.).

“Outsiders” can also have accounts but, the those of the old Lipforge system can not be recovered. “Outsiders” will have to apply again for a new account. After 8 years of operation, this allows for a welcomed user base clean-up, for many accounts created a long time ago are obsolete now.

Project managers will have to integrate again all the participants to their projects, as the data format between systems is incompatible and the match between old and new user accounts impossible. Of course project manager will be provided with the list of their current project participants.


shareright © 2002 Phlash