Talk:The Case for Using Wiki Version History: Difference between revisions
| Line 18: | Line 18: | ||
== 2. Visual Version History == | == 2. Visual Version History == | ||
I think that Visual Version History should not be a problem, you can either just continue using the wiki and then link to the git files. Even better, the visual version history could be automatically created as a commit hook and on GitLab. | Q. I think that Visual Version History should not be a problem, you can either just continue using the wiki and then link to the git files. Even better, the visual version history could be automatically created as a commit hook and on GitLab. | ||
A. Could be created: a visual gallery like in the wiki, but it already exists in Mediawiki so why reinvent the wheel? The wiki already has all the formatting to make this easy. And we don't want to require people understanding how to use Git platforms, which is a higher learning curve than a wiki. | |||
== 3. Collaboration at a scale == | == 3. Collaboration at a scale == | ||
Revision as of 01:58, 8 February 2021
I agree that given that you are using a wiki as a repository you would want to just upload a new version of a file and use it. I just think that MediaWiki was not intended to be used as a repository.
If I understand correctly the reason you gave for not using Git are
- You don't control the data with Gitlab
- Visual Version History
- Collaboration on a scale
- It is currently used for a large set of parts (this was not included originally but I think it is important)
I still think Git has major advantages and want to give counterpoints to the arguments above
1. You don't control the data with Gitlab
Q: I don't understand this, why don't you own the data, you can host it on your server.
A: Then why not just use our server? This means that we're hosting the data in 2 places, so why not just host it on our servers? And if Gitlab decides to end service, we have to have a local backup. Or if it changes its interface or usage terms, we may have to rework significant parts of our workflow. We need absolute control of our data as we are a long-term project.
2. Visual Version History
Q. I think that Visual Version History should not be a problem, you can either just continue using the wiki and then link to the git files. Even better, the visual version history could be automatically created as a commit hook and on GitLab.
A. Could be created: a visual gallery like in the wiki, but it already exists in Mediawiki so why reinvent the wheel? The wiki already has all the formatting to make this easy. And we don't want to require people understanding how to use Git platforms, which is a higher learning curve than a wiki.
3. Collaboration at a scale
I think there is a case that the access privileges are much better with Git. I believe that pull requests are probably necessary on a very large scale collaboration.
4. It is currently used for a large set of parts
I think this point is very strong and that the transition could be a lot of work. But I still think that it could be worth it, and it should be tried out.