Hidde, this is a good question. What was your team size when you migrated to GitLab?
Trac features that are not GitLab features:
Low cost
Trac runs on a $5/mo VPS. Many Trac instances can share a $5/mo VPS with many websites. The last time I evaluated GitLab, it needed a dedicated $20/mo VPS to get started.
Low admin overhead
Trac installs quickly, on most any server platform. The maintenance overhead on these has been near zero. There is no constant slog of platform updates, feature changes, plugin updates, etc. I assume GitLab has this slog, as it's a "Everything + Kitchen Sink" type of platform. Perhaps I'm wrong?
Maturity
Trac has been in use and maintained for a long time. This kind of tool isn't sexy to young developers who want hip new exciting things. I'm a greybeard, maintaining a few Perl projects, and I don't want to be excited. I want my tool to do it's job well and not occupy my time.
The largest team I manage is a half-dozen part time volunteers for a non profit. (Herding volunteer cats is worse than herding cats.) This team might benefit from GitLab or Jira, but the org doesn't want to budget for it.
You've have interested me in evaluating GitLab again. It's been several years. At this point, I am managing Trac instances for clients on several $5/mo VPS. If I consolidate all of them into a single GitLab instance with a $20/mo VPS, I could save a little money.
Programmer and mathematician. Problem solver. Lover of clean code, coffee, cycling, running and Italian food.
Kotlin, Java, Spock (Groovy), PHP, Angular, MariaDB, ...
Around 6 persons. We took the step because there was a (partial) simple migration script, and the feature set of GitLab was greater. Mostly the useability of the interface was a lot better, which increased the productivity, communication and 'purposefulness' (is that a word) of the team.
Considering renting a VPS. You are probably right, there is more performance/storage/memory required per instance of GitLab. The most low cost solution might be better in your case. However, GitLab also has a hosted variant (gitlab.com/) which runs the Community Edition which is free to use (but your data is on their servers...).
The admin overhead is not an issue in my experience: The Omnibus package has around 1/month updates, is well maintained and is easy to update (usually a package manager, migration works out of the box).
Maturity: this might be an issue. GitLab is a very quickly innovating platform. In a few years they developed a modern application which now influences the big players like GitHub and Jira. However, I've noticed few bugs in the day-to-day usage, and if you stay one major version behind there are probably no issues.
Programmer and mathematician. Problem solver. Lover of clean code, coffee, cycling, running and Italian food.
Kotlin, Java, Spock (Groovy), PHP, Angular, MariaDB, ...
Great to hear. At the time, as far as I can remember, we used the script as can be found on github.com/moimael/trac-to-gitlab. It converts the most basic infrastructure entities to similar GitLab entities. Then, we manually added/updated some labels, and started using some of the GitLab features which were not available in Trac.
Also, we noticed some changes in our team workflow after the migration. Because of that, we changed some workflow specific things like labels and pipeline scripts to suit our needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hidde, this is a good question. What was your team size when you migrated to GitLab?
Trac features that are not GitLab features:
Low cost
Trac runs on a $5/mo VPS. Many Trac instances can share a $5/mo VPS with many websites. The last time I evaluated GitLab, it needed a dedicated $20/mo VPS to get started.
Low admin overhead
Trac installs quickly, on most any server platform. The maintenance overhead on these has been near zero. There is no constant slog of platform updates, feature changes, plugin updates, etc. I assume GitLab has this slog, as it's a "Everything + Kitchen Sink" type of platform. Perhaps I'm wrong?
Maturity
Trac has been in use and maintained for a long time. This kind of tool isn't sexy to young developers who want hip new exciting things. I'm a greybeard, maintaining a few Perl projects, and I don't want to be excited. I want my tool to do it's job well and not occupy my time.
The largest team I manage is a half-dozen part time volunteers for a non profit. (Herding volunteer cats is worse than herding cats.) This team might benefit from GitLab or Jira, but the org doesn't want to budget for it.
You've have interested me in evaluating GitLab again. It's been several years. At this point, I am managing Trac instances for clients on several $5/mo VPS. If I consolidate all of them into a single GitLab instance with a $20/mo VPS, I could save a little money.
Around 6 persons. We took the step because there was a (partial) simple migration script, and the feature set of GitLab was greater. Mostly the useability of the interface was a lot better, which increased the productivity, communication and 'purposefulness' (is that a word) of the team.
Considering renting a VPS. You are probably right, there is more performance/storage/memory required per instance of GitLab. The most low cost solution might be better in your case. However, GitLab also has a hosted variant (gitlab.com/) which runs the Community Edition which is free to use (but your data is on their servers...).
The admin overhead is not an issue in my experience: The Omnibus package has around 1/month updates, is well maintained and is easy to update (usually a package manager, migration works out of the box).
Maturity: this might be an issue. GitLab is a very quickly innovating platform. In a few years they developed a modern application which now influences the big players like GitHub and Jira. However, I've noticed few bugs in the day-to-day usage, and if you stay one major version behind there are probably no issues.
Would be interested in what you used to migrate from Trac->Gitlab as we're about to try it...
Great to hear. At the time, as far as I can remember, we used the script as can be found on github.com/moimael/trac-to-gitlab. It converts the most basic infrastructure entities to similar GitLab entities. Then, we manually added/updated some labels, and started using some of the GitLab features which were not available in Trac.
Also, we noticed some changes in our team workflow after the migration. Because of that, we changed some workflow specific things like labels and pipeline scripts to suit our needs.