Align "Upgrade from Gogs" document with more recent versions of Gogs

[cez81]

• Gitea version (or commit ref): N/A
• Git version: N/A
• Operating system: N/A
• Database (use [x]): N/A
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io: N/A
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

https://docs.gitea.io/en-us/upgrade-from-gogs/ is not up to date with more recent versions of Gogs. For example it mentions gogs dump but it was replaced with gogs backup in v0.10.8.

I'm not even sure it's still possible to migrate from current version of Gogs...

[4oo4]

I just did a manual migration from gogs by copying over these tables from the gogs (MySQL) database into the gitea one (I omitted tables without data, there may be others that need to be copied):

action
attachment
comment
follow
issue_label
issue
issue_user
label
milestone
public_key
pull_request
repository
star
team

The migration seemed to work without totally breaking the app, but I get 404s now when I try to browse to a repo, or issue, I'll see if it's possible to fix that.

Looks like the issue is that the repository permissions did map over properly because of the repo_units table (#1794):

routers/repo/view.go:291 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access

[Jackysi]

Yea same issue here

[4oo4]

@Jackysi Luckily since I don't have a ton of repos I was able to fix mine by following this to recreate the missing repo_units table. Then to fix issues/PRs, you have to go turn on those features for each repo.

For type I set that to 1 and set config to {}, then just added the repo_id and created_unix from the repositories table for each repo. So when you're done, the table should look like this:

+----+---------+------+-------+--------+--------------+
| id | repo_id | type | index | config | created_unix |
+----+---------+------+-------+--------+--------------+
| 69 |      16 |    1 |     1 | {}     |   1490025629 |
| 70 |      16 |    2 |     2 | {}     |   1490025630 |
| 71 |      16 |    3 |     3 | {}     |   1490025630 |
| 72 |      16 |    4 |     4 | {}     |   1490025630 |
| 73 |      16 |    5 |     5 | {}     |   1490025630 |
| 74 |      16 |    6 |     6 | {}     |   1490025630 |
| 75 |      16 |    7 |     7 | {}     |   1490025630 |
+----+---------+------+-------+--------+--------------+

The above example has different things for type, not sure what all those values mean, but the important thing is that it 's not empty.

Depending on what features were used in Gogs there more manual building of tables would probably be needed (Gitea has some tables like repo_units that don't exist in Gogs), but this at least allows one to bring over all their repos, PRs and issues.

[Schroedingers-Cat]

Before I migrated to gitea, I used gogs backup (on Ubuntu, run this in the path /opt/gogs) to dump the database, unzipped it, changed the Version.json from 17 to 15 and used again gogs to restore the database. This way, I had no database problems when using gitea 1.4 rc1. All my repos can be browsed including issues and I can pull and push.

However, I just found something strange in the logs:

2018/02/12 02:09:21 [W] SyncReleasesWithTags: GetTags: exit status 128 - fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

What could that be?
Also, created an additional folder in my repositories folder called error. Now that doesn't sound good. What's going on there?

[Jackysi]

I spent more time trying to fix the database (repo_units) etc than I would resetting my gogs setup. So I've started from scratch (except the config). Got it running pretty fast ^^.

I love that Gitea has API, but its lacking some cool features like github has. Specially downloading release by API key / token (sadly my Go knowledge is limited to add this) and few API calls like getting Tags (I fixed that by editing code and changing "tags: false" to true on the Releases route controller.

Anyhow. Great project. Love it. Love performance and all about it =) Might contribute when my Go knowledge gets far enough!

[codescale]

We managed to migrate from gogs 0.11.34 to gitea 1.3.3
Actually it was easier then expected :)

There was only one problem with the MariaDB when gogs/gitea complained about a

max key length is 767 byte

We installed this patch before we started with the migration and after that, everything was flawless.

1. To backup all your data on gogs you can follow this HowTo. Or just backup the data from your gogs install folder manually and dump the DB with mysqldump -u <user> -p<pswd> -v <gogs_db_name> > gogs_db_backup.sql.

2. Create you new install folder for gitea (e.g. /opt/gitea/) and copy the folder custom and data from the gogs install folder into the new gitea folder

3. mv $gogs_path/custom/conf/app.ini $gitea_path/custom/conf/gogs_app.ini

4. wget https://raw.githubusercontent.com/go-gitea/gitea/v$gitea_version/conf/app.ini -P $gitea_path/custom/conf

5. wget https://dl.gitea.io/gitea/1.0.1/gitea-1.0.1-linux-amd64 -P $gitea_path

6. $gitea_path/gitea-1.0.1-linux-amd64 web

7. Open the gitea website in your browser of choice and finish the setup ... look at your previous configuration at $gitea_path/coustom/conf/gogs_app.ini

8. Stop gitea

9. wget https://dl.gitea.io/gitea/1.2.0/gitea-1.2.0-linux-amd64 -P $gitea_path

10. $gitea_path/gitea-1.2.0-linux-amd64 web and let the migration take place (see gitea logs for details)

11. Stop gitea again and to the same for version 1.3.3

=> done 👍 maybe this helps others how want to do the migration too...

[lunny]

#3516 are also trying to resolve the max key length is 767 byte problem.

[appleboy]

Update documentation. See: #3559

[lunny]

Should be resolved by #3559

[amit-handa]

@Schroedingers-Cat I am facing the same issue "Not a git repository ..."
Have you managed to solve it ? I have landed on gitea via migration from gogs. Its my first time using gitea.

Thanks,

[Schroedingers-Cat]

@amit-handa
That error was just written in the log files. The actual interactions with the repositories from the webinterface were all possible. As nobody from the dev team (I also asked about this on the discord server) seemed to have an idea what was going on there, I just ignored it because everything was working fine.